DESC: FORM 2 THE PATENTS ACT, 1970 (39 of 1970) & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION (See section 10 and rule 13) 1. TITLE OF THE INVENTION SYSTEM AND METHOD FOR PROCESSING CALL-BACK REQUESTS 2. APPLICANT(S) Name Nationality Address JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India 3. PREAMBLE TO THE DESCRIPTION The following specification particularly describes the invention and the manner in which it is to be performed. RESERVATION OF RIGHTS [0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and/or trade dress protection, belonging to JIO PLATFORMS LIMITED (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. FIELD OF THE DISCLOSURE [0002] The present disclosure relates generally to the field of wireless communication systems. More particularly, the present disclosure relates to a system and a method for processing call-back requests. DEFINITION [0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise. [0004] The expression “call-back request” refers to a service where a user can register a request to get a call-back from a service provider (for example, a call center) at the user's preferred time. [0005] The expression “call-back” refers to a process of scheduling a return call to a user instead of having the user wait on hold. [0006] The expression “call-back data” refers to information collected and managed regarding call-back requests and interactions. The call-back data is used to optimize service providers’ operations, improve user satisfaction, and ensure adequate follow-up. In an example, call-back data may include a preferred time of the user for a call-back. [0007] The expression “system restart” refers to a process in which a system is completely turned off and then turned back on again. [0008] The expression “process failover” refers to a mechanism designed to maintain the uninterrupted operation of a system by shifting the workload or process management to a standby or backup process when the primary method fails. [0009] The expression “queues” refers to one or more lists where call-back requests from users are logged and managed. The queues ensure that each call-back request is processed systematically and prioritized based on urgency or user priority. [0010] The expression “time slot” refers to a specific, pre-defined interval or segment of time within a schedule or timeline used to organize and manage activities or tasks. For example, a time slot refers to a designated period during which a particular action, such as placing a call-back to a user, is scheduled to occur. Each time slot typically has a start and end time and can be configurable according to specific requirements, such as service provider or user preferences. [0011] The expression “system cyclic timer” refers to a software or hardware mechanism that generates periodic interrupts or events at regular, pre-defined intervals. [0012] The expression “retry cyclic timer” refers to a type of cyclic timer used to repeatedly attempt an action or operation at regular intervals, particularly when an initial attempt has failed. [0013] The expression “failed calls” refers to instances where attempts to return a user's call or fulfill a call-back request fail. The reasons for failed calls include technical issues (e.g., network problems, telephony failures, timeouts, network connection errors, server downtime), configuration errors (incorrect settings, expired credentials), and customer unavailability (no response, busy lines, etc.). [0014] The expression “re-attempt the call” refers to attempting to contact the user after an initial call has failed or been unsuccessful. [0015] The expression “pre-configured number of retries” refers to a specific, predetermined limit on the number of times an action or process will be attempted before considering it a failure. The limit may be established based on system settings or configuration parameters. [0016] The expression “pre-determined frequency” refers to a specific, established rate at which an action or event is scheduled to occur. [0017] The expression “user-defined criteria” refers to specific rules, parameters, or standards the user sets that guide a system or process. These criteria are customizable according to the user's needs or preferences, allowing for personalized or tailored functionality. [0018] The expression “check-point the call-back data” refers to creating a saved state of the data at a specific point in time. This process ensures that the data can be recovered or restored from that saved state in case of system failures, restarts, or crashes. [0019] The expression “mate process” refers to storing the call-back data in a duplicate or secondary system, ensuring that the call-data is preserved and accessible even if the primary process encounters issues. [0020] The expression “pre-determined time interval” refers to a specific duration set or established in advance for a particular action or process. [0021] The expression “agent” refers to a person responsible for answering the call initiated by the system in response to a user's request. The agent engages with the user to address their inquiries, resolve issues, provide information, or assist with transactions. In some examples, the agent may refer to an automated system or software, such as a chatbot, virtual assistant, or interactive voice response (IVR) system, that interacts with the users without human intervention. The agent may handle tasks such as answering queries, processing transactions, or providing user support based on predefined rules, artificial intelligence, or machine learning algorithms. [0022] The expression “one or more service provider requirements” refers to the specific criteria, conditions, or preferences established by the service provider that dictate how the system should be configured and operated. [0023] The expression “Session Initiation Protocol (SIP)” refers to a signaling protocol used to establish, maintain, and terminate real-time communication sessions over Internet protocol (IP) networks. The SIP is widely utilized in voice-over IP (VoIP), video conferencing, and other multimedia communication applications. [0024] The expression “Internet protocol (IP) Multimedia Subsystem (IMS)” refers to a standardized architecture used to deliver IP-based multimedia services, such as voice, video, and messaging, over broadband networks. [0025] The expression “Online Charging System (OCS)” refers to a real-time system that manages and processes billing, charging, and account balances for telecommunications services as they are used. [0026] The expression “Common API Framework (CAPIF)” refers to a standardized framework for developing and managing APIs that facilitate integration between different systems and components. The CAPIF ensures seamless interoperability and communication among diverse software systems and hardware components. [0027] The expression “Diameter” refers to a protocol used for authentication, authorization, and accounting (AAA) in network environments. [0028] The expression “Diameter Routing Agent (DRA) refers to a network component used in Diameter-based systems to manage and route Diameter messages between nodes in a telecommunications network. [0029] The expression “Caller Ring back Tones (CRBT)” refers to personalized audio tones that callers hear while waiting for their call to be answered, replacing the standard ringing sound with music, messages, or other content chosen by the call recipient. [0030] The expression “Media Resource Function (MRF)” refers to a network component providing media processing capabilities within multimedia communication systems, such as conferencing, playback, and recording. [0031] The expression “Element Management System (EMS)” refers to a network management system that focuses on configuring, monitoring, and maintaining individual network elements or devices. [0032] The expression “Operational Support System (OSS)” refers to a comprehensive framework used for managing, controlling, and optimizing telecommunications network operations and services, including provisioning, fault management, and performance monitoring. [0033] The expression “Business Support System (BSS)” refers to a set of software applications and tools used for managing and supporting business processes in telecommunications, such as billing, customer relationship management, and service provisioning. [0034] The expression “Load Balancer” refers to a device or software application that distributes network or application traffic across multiple servers to ensure no single server becomes overwhelmed. [0035] The expression “Telephony Application Server (TAS)” refers to a platform that provides telephony services and application support, enabling advanced call processing, messaging, and integration with communication networks. [0036] The expression “Hypertext Transfer Protocol (HTTP)” refers to a protocol, a set of rules and conventions for communication between computers over the network. It is the foundation of data communication on the World Wide Web. It is designed to facilitate the exchange of information between clients (such as web browsers) and servers (where websites and web applications reside). [0037] The expression “Adaptive Troubleshooting and Operations Management (ATOM)” refers to a platform designed to improve how organizations handle operational issues and manage ongoing processes. [0038] The expression “Request Callback application programming interface (API) (HTTP)” refers to an interface that allows applications to request a call-back or to schedule a call-back operation over HTTP. The API involves making HTTP requests to a server to initiate a call-back process, which can be used in various scenarios such as customer support, notifications, or service integration. [0039] The expression “INVITE (w/o session description protocol (SDP))” refers to an invite used to initiate a communication session or invite participants to a session without the SDP. The SDP format describes multimedia communication sessions, including details like media types (audio, video), codecs, network information, and session attributes. [0040] These definitions are in addition to those expressed in the art. BACKGROUND [0041] The following description of 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 be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art. [0042] “Request-a-call back” is a standard service provided by service providers such as call centers and customer support departments. A user can register a request to receive a call-back at a convenient time rather than waiting on hold. For instance, the user can specify a preferred time for the call-back. The “Request-a-call back” service aims to improve customer satisfaction and reduce wait times. However, this service has implementation challenges, such as registering multiple call-backs and triggering calls as per the requested time, as it requires multiple timers to be started at the application end. For example, each call must be scheduled so that the timer is required to be started at the exact time so that a user gets a call. Additionally, call-back data retention is one of the challenges faced, especially in system restart or process failover. [0043] Accordingly, there is a need for an efficient request-a-call-back architecture or design. SUMMARY [0044] In an exemplary embodiment, a system for processing a call-back request is described. The system comprises an execution unit configured to maintain a queue for each time slot of a plurality of time slots and receive the call-back request from a user. The call-back request comprises call-back data indicative of a preferred time for a call-back. The execution unit is further configured to store the call-back request in the queue maintained for a corresponding time slot that matches the preferred time and execute a system cyclic timer to scan each queue according to time slots. A determination unit coupled with the execution unit is configured to retrieve the call-back request from the corresponding queue based on the time slot, execute a call for the user with an agent responsive to the call-back request at the preferred time of the user, process the call to determine whether the call was successfully executed. In response to determining that the call was not successfully executed, the determination unit is configured to execute a retry cyclic timer to re-attempt the call after a pre-determined time interval. [0045] In some embodiments, the execution unit is configured to store the call-back request in a database. [0046] In some embodiments, in response to determining that the call was unsuccessful, the determination unit is configured to retrieve the call-back request from the database and re-attempt the call after the predetermined time interval. [0047] In some embodiments, the execution unit is configured to check-point the call-back data to a mate process. [0048] In some embodiments, the determination unit is configured to notify the user if a call-back attempt fails after a pre-configured number of retries. [0049] In some embodiments, the determination unit is configured to execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a pre-determined frequency. [0050] In some embodiments, each time slot is configurable according to one or more service provider requirements. [0051] In another exemplary embodiment, a method for processing a call-back request. The method includes maintaining, by an execution unit, a queue for each time slot of a plurality of time slots. The method includes receiving, by the execution unit, the call-back request from a user, where the call-back request comprises call-back data indicative of a preferred time for a call-back. The method includes storing, by the execution unit, the call-back request in the queue maintained for a corresponding time slot that matches the preferred time. The method includes executing, by the execution unit, a system cyclic timer to scan each queue according to time slots. The method includes retrieving, by the determination unit, the call-back request from the corresponding queue based on the time slot. The method includes executing, by the determination unit, a call for the user with an agent responsive to the call-back request at the preferred time of the user. The method includes processing, by the determination unit, the call to determine whether the call was successfully executed. The method includes, in response to determining that the call was not successfully executed, executing, by the determination unit, a retry cyclic timer to re-attempt the call after a pre-determined time interval. [0052] In some embodiments, the method further comprises storing, by the execution unit, the call-back request in a database. [0053] In some embodiments, in response to determining that the call was unsuccessful, retrieving, by the determination unit, the call-back request from the database and re-attempt the call after the predetermined time interval. [0054] In some embodiments, the method further comprises check-pointing, by the execution unit, the call-back data to a mate process. [0055] In some embodiments, the method further comprises notifying, by the determination unit, the user if a call-back attempt fails after a pre-configured number of retries. [0056] In some embodiments, the method further comprises executing, by the determination unit, the retry cyclic timer to scan a list of failed calls and re-attempting, by the determination unit, the failed calls at a pre-determined frequency. [0057] In some embodiments, each time slot is configurable according to one or more service provider requirements. [0058] In yet another exemplary embodiment, a user equipment (UE) communicatively coupled with a network. The coupling comprises receiving, by the network, a connection request from UE, sending, by the network, an acknowledgment of the connection request to the UE, and transmitting a plurality of signals in response to the connection request. The network is configured for performing a method for processing a call-back request. The method comprises maintaining a queue for each time slot of a plurality of time slots and receiving the call-back request from a user. The call-back request comprises call-back data indicative of a preferred time for a call-back. The method further comprises storing the call-back request in the queue maintained for a corresponding time slot that matches the preferred time, executing a system cyclic timer to scan each queue according to time slots, retrieving the call-back request from the corresponding queue based on the time slot, executing a call for the user with an agent responsive to the call-back request at the preferred time of the user, processing the call to determine whether the call was successfully executed, and in response to determining that the call was not successfully executed, executing a retry cyclic timer to re-attempt the call after a pre-determined time interval. OBJECTIVES [0059] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows: [0060] An objective of the present disclosure is to provide an efficient request-a-call-back architecture or design. [0061] Another objective of the present disclosure is to maintain queues for call-back requests received from users for each time slot. [0062] Another objective of the present disclosure is to store call-back data in a database and check-point the call-back data to mate process. [0063] Yet another objective of the present disclosure is to run a system cyclic timer continuously to scan each time slot as per current time. [0064] Yet another object of the present disclosure is to run a retry cyclic timer to scan a list of failed calls. [0065] Yet another object of the present disclosure is to re-attempt the failed calls for a configured number of times before marking the calls as failed. [0066] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING [0067] 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. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components. [0068] FIG. 1 illustrates an exemplary network architecture for implementing a system for processing a call-back request, in accordance with an embodiment of the present disclosure. [0069] FIG. 2 illustrates an exemplary block diagram of the system for processing the call-back request, in accordance with an embodiment of the present disclosure. [0070] FIG. 3A illustrates an exemplary system architecture of the system, in accordance with an embodiment of the present disclosure. [0071] FIG. 3B illustrates another exemplary system architecture for implementing the system, in accordance with an embodiment of the present disclosure. [0072] FIG. 4 illustrates an exemplary flow diagram describing “request-a-call-back” service, in accordance with an embodiment of the present disclosure. [0073] FIG. 5 illustrates an exemplary flow diagram of a method for processing a call-back request, in accordance with an embodiment of the present disclosure. [0074] FIG. 6 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented. [0075] The foregoing shall be more apparent from the following more detailed description of the disclosure. LIST OF REFERENCE NUMERALS 100 Network architecture 102 User(s) 104 User Equipments (UEs) 106 Network 108 System 200 Block diagram 202 Processor(s) 204 Memory 206 Interface(s) 210 Database 214 Execution unit 216 Determination unit 300A System architecture 306 Internet protocol (IP) multimedia subsystem (IMS) 308 Mobile number portability (MNP) 310 Online charging system (OCS) 312 Diameter routing agent (DRA) 314 Caller ring back tone (CRBT) 316 Media resource function (MRF) 318 Element management system (EMS) 320 Operations support system/business support system (OSS/BSS) 322 Load Balancer 300B System Architecture 323 Evolved Packet System (EPS) 324 Provisioning server 330 Telephony Application Server (TAS) unit 350 Common API framework (CAPIF) 352 Adaptive troubleshooting and operations management (ATOM) platform 354 Charging function (CHF) 356 Subscription engine 358 Fulfilment management system (FMS) 360 Unified inventory manager (UIM) 362 Market place and self-care portal 400 Flow Diagram 402 Customer Care 404 Interconnection border control function (IBCF) 500 Flow Diagram 600 Computer system 610 External Storage Device 620 Bus 630 Main Memory 640 Read Only Memory 650 Mass Storage Device 660 Communication Port 670 Processor DETAILED DESCRIPTION [0076] 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 can 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. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings. [0077] 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. [0078] 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, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments. [0079] Also, it is noted that individual embodiments may be described as a process that 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 can 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. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function. [0080] 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 like the term “comprising” as an open transition word without precluding any additional or other elements. [0081] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. [0082] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein. [0083] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical and computing device. The user device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery and an input-means such as a hard keypad and/or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure. [0084] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The 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 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 is a hardware processor. [0085] As portable electronic devices and wireless technologies continue to improve and grow in popularity, the advancing wireless technologies for data transfer are also expected to evolve and replace the older generations of technologies. In the field of wireless data communications, the dynamic advancement of various generations of cellular technology are also seen. The development, in this respect, has been incremental in the order of second generation (2G), third generation (3G), fourth generation (4G), fifth generation (5G), sixth generation (6G), and more such generations are expected to continue in the forthcoming time. [0086] Radio Access Technology (RAT) refers to the technology used by mobile devices/ user equipment (UE) to connect to a cellular network. It refers to the specific protocol and standards that govern the way devices communicate with base stations, which are responsible for providing the wireless connection. Further, each RAT has its own set of protocols and standards for communication, which define the frequency bands, modulation techniques, and other parameters used for transmitting and receiving data. Examples of RATs include Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), Long-Term Evolution (LTE), 5G, and 6G. The choice of RAT depends on a variety of factors, including the network infrastructure, the available spectrum, and the mobile device's/device's capabilities. Mobile devices often support multiple RATs, allowing them to connect to different types of networks and provide optimal performance based on the available network resources. [0087] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation. [0088] “Request-a-call back” is a standard service provided by service providers such as call centers and customer support departments. A user can register a request to receive a call-back at a convenient time rather than waiting on hold. For instance, the user can specify a preferred time for the call-back. The “Request-a-call back” service aims to improve customer satisfaction and reduce wait times. However, this service has implementation challenges, such as registering multiple call-backs and triggering calls as per the requested time, as it requires multiple timers to be started at the application end. For example, each call must be scheduled so that the timer is required to be started at the exact time so that a user gets a call. Additionally, call-back data retention is one of the challenges faced, especially in system restart or process failover. [0089] Accordingly, there is a need for systems and methods for processing call-back requests from users. [0090] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs 1-6. [0091] FIG. 1 illustrates an exemplary network architecture (100) for implementing a system (108) for processing a call-back request, in accordance with an embodiment of the present disclosure. [0092] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N) in an environment. A person of ordinary skill in the art will understand that one or more users (102-1, 102-2…102-N) may collectively be referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2…104-N) may collectively be referred to as the UE (104). Although only three UE (104) are depicted in FIG. 1, however, any number of the UE (104) may be included without departing from the scope of the ongoing description. [0093] In an embodiment, the UE (104) may include smart devices operating in a smart environment, for example, an Internet of Things (IoT) system. In such an embodiment, the UE (104) may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, smart security system, smart home system, other devices for monitoring or interacting with or for the users (102) and/or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but not limited to, intelligent, multi-sensing, network-connected devices, which may integrate seamlessly with each other and/or with a central server or a cloud-computing system or any other device that is network-connected. [0094] Additionally, in some embodiments, the UE (104) may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and/or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or the entity such as touchpad, touch-enabled screen, electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE (104) may not be restricted to the mentioned devices and various other devices may be used. [0095] Referring to FIG. 1, the UE (104) may communicate with the system (108) through a network (106) for sending or receiving various types of data. In an embodiment, the network (106) may include at least one of a 5G network, 6G network, or the like. The network (106) may enable the UE (104) to communicate with other devices in the network architecture (100) and/or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like. [0096] In an embodiment, the network (106) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network (106) may also include, by way of example but not limitation, one or more of a radio access network (RAN), a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. [0097] In an embodiment, the UE (104) is communicatively coupled with the system (108). The system (108) may receive a connection request from the UE (104). The system (108) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. The system (108) may be configured for processing a call back request. [0098] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100). [0099] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for processing the call-back request, in accordance with an embodiment of the present disclosure. [00100] Referring to FIG. 2, in an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (204) may include any non-transitory storage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like. [00101] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may include a variety of interfaces, for example, interfaces for data input and output devices (I/O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a database (210), an execution unit (214) and a determination unit (216). [00102] The system includes the execution unit (214) and the determination unit (216). [00103] In an aspect, the execution unit (214) is configured to maintain a queue for each time slot of a plurality of time slots. The queue is maintained for each time slot to store a plurality of call-back requests from the plurality of users (102) (interchangeably referred to as customers). In an implementation, the execution unit (214) is configured to receive a call-back request from a user (102). The call-back request includes call-back data indicative of a preferred time for a call-back. The preferred time for a call-back refers to a specific time or a time slot when the user (102) would like to be contacted or receive a return call. [00104] The execution unit (214) is further configured to store the call-back request in the queue maintained for a corresponding time slot that matches the preferred time or in which the preferred time falls. In an aspect, the request will be stored in the queue that matches with time slot preferred by the customer. For example, if the customer prefers to be called back between 2 PM and 3 PM, the callback request will be stored in the queue for that specific time slot (i.e., 2 PM to 3 PM). [00105] The execution unit (214) further stores the call-back request and associated call-back data in the memory (204) and/or the database (210). The call-back data is used to manage and track the call-back request. Furthermore, the execution unit (214) is further configured to check-point the call-back data to a mate process. The call-back data is check-pointed to ensure the call-back is performed at the preferred time. [00106] The execution unit (214) is configured to periodically or continuously execute a system cyclic timer to scan each queue according to time slots. The system cyclic timer is used to manage and schedule the call-back to the user (102). The system cyclic timer assists in handling the call-backs promptly and improves customer satisfaction. Each time slot is configurable according to one or more service provider requirements, such as operational hours, resource availability, and compliance and service level agreements (SLAs). [00107] The determination unit (216) is configured to retrieve the call-back request of the user (102) from the corresponding queue based on the time slot. The determination unit (216) executes a call for the user (102) with an agent responsive to the call-back request at the preferred time of the user (102). For example, if the customer's preferred time for a callback is between 2 PM and 3 PM, the agent responsible for the callback request may perform the callback within that time period (i.e., 2 PM to 3 PM). The determination unit (216) is configured to process the call to determine whether the call was successfully executed. In response to determining that the call was not successfully executed, the determination unit (216) may retrieve the call-back request and associated call-back data from the memory (204) and/or the database (210). [00108] In an implementation, the determination unit (216) may retrieve the call-back request and associated call-back data from the memory (204) and/or the database (210) based at least on one of system restart and process failover. The system restart includes, but is not limited to, software updates, performance issues, configuration changes, system error, security measures, resource management, network changes, scheduled maintenance. The process failover includes, but is not limited to, server crash, network outage, software bug, overload, high traffic, system updates, scheduled maintenance, power outages, connectivity loss, security incidents, etc. [00109] The determination unit (216) may execute a retry cyclic timer to re-attempt the call after a pre-determined time interval. For example, the pre-determined time interval may be a 10-minute period set between retries for a failed call attempt. The pre-determined time interval may indicate that the determination unit (216) waits for 10 minutes before attempting to make the call again. In an implementation, the determination unit (216) is configured to re-attempt (call-back attempt) the failed call for a pre-configured number of retries before marking the call as failed. The pre-configured number of retries refers to a specific, predetermined limit on the number of times the system will attempt to perform an action, such as making a call-back, after an initial failure. For example, if a call attempt fails, the system (108) may be set to automatically retry the making the call up to three times before stopping or marking the call as failed. In an implementation, the determination unit (216) is configured to notify the user (102) if the call-back attempt fails after the pre-configured number of retries. After making three attempts, the user will be informed about the callback attempts and the fact that three callbacks were made. [00110] Although the above description is provided with respect to a single call-back request, in some embodiments, the determination unit (216) may process a plurality of call-back requests received from a plurality of users (102) in a similar manner as described above. The call-back requests and associated call-back data may be stored in the memory (204) and/or the database (210). In an implementation, the determination unit (216) may execute the retry cyclic timer to scan a list of failed calls and re-attempt the failed calls at a pre-determined frequency. The pre-determined frequency may specify that retry attempts should occur every 20 minutes. For instance, the determination unit (216) will wait 20 minutes after a failed attempt before making another retry attempt based on the preconfigured settings. The list of failed calls may also be stored in the memory (204) and/or the database (210). [00111] The determination unit (216) may retrieve the list of failed calls and associated call-back data from the memory (204) and/or the database (210). The list of failed calls is retrieved to identify the calls that didn’t succeed. The list of failed calls and associated call-back data is used to manage the call-back process. [00112] In an aspect, the determination unit (216) may then prioritize the failed calls based on user-defined criteria. The user-defined criteria include, but are not limited to, time of the failed calls, type of caller, reason for the failure, frequency of calls, etc. The time of the failed calls is a criterion that considers when the call attempt was made. The calls that occurred more recently may be given higher priority for callbacks. The type of caller is a criterion that categorizes callers based on predefined classifications. Certain types of callers can be given priority over others. For example, high-value clients or clients with a history of significant transactions may be prioritized to maintain customer satisfaction and loyalty. Calls from business clients might be prioritized over regular consumers. The reason for the failure is a criterion that assesses why the call failed. The failure reasons can indicate varying levels of urgency. For example, a call that resulted in no answer might be treated as less urgent than the call that encountered a busy signal or was intentionally dropped. The calls that failed due to technical problems might also be prioritized differently, especially if the caller reported an ongoing issue. The frequency of calls is a criterion that tracks how many times a particular number has attempted to reach out. Frequent callers might indicate a more pressing need for assistance. [00113] In an aspect, the retry cyclic timer is triggered at the predetermined frequency to reattempt the call-back execution for the failed calls. The call-back execution is reattempted at the predetermined frequency (i.e., predefined time intervals) for the failed calls. By reattempting failed calls at the predefined time intervals, the chances of reaching out to customers who may need assistance or have important inquiries are enhanced. This helps in reducing response times and ensures that failed calls are not overlooked. [00114] FIG. 3A illustrates an exemplary system architecture (300A) of the system (108), in accordance with an embodiment of the present disclosure. [00115] As shown in FIG. 3A, the system architecture (300A) includes user equipment (UE) (104) and an internet protocol (IP) multimedia subsystem (IMS) (306). The system architecture (300A) may include a number of components (modules) such as a mobile number portability (MNP) (308), online charging system (OCS) (310), diameter routing agent (DRA) (312), caller ring back tone (CRBT) (314), media resource function (MRF) (316), element management system (EMS) (318), operations support system/business support system (OSS/BSS) (320), load balancer (322), provisioning server (324), and a telephony application server (TAS) unit (330). The system architecture (300A) may be 4G, 5G, or 6G network architecture. The UE (104) is connected to the IMS (306) via the Session Initiation Protocol (SIP) to manage and control multimedia communication sessions. [00116] In an implementation, the TAS unit (330) may be a collaborative framework to rapidly develop and fulfill the service needs of enterprise and residential customers. The TAS unit (330) may be a SIP application server interacting with core IMS to host a wide array of cloud telephony enterprise services. In an implementation, the execution unit (214) of the system (108) may be implemented within the TAS unit (330). The UE (104) may be a Voice over LTE (VoLTE) device that a user may use to register a request to receive a call-back at a preferred time. The IMS (306) is a standard-based architectural framework for delivering multimedia communications services such as voice, video, and text messaging over IP networks. In an implementation, the IMS (306) may be an architecture that works with 4G, 5G, or 6G mobile core networks to deliver voice calls, messages, and other potential real-time services. The MNP (308) allows a telecom service user to move from one operator to another operator, irrespective of geographical area. The OCS (310) is a system that allows communications service providers to charge their customers in real-time based on service usage. The DRA (312) is a functional element that provides real-time routing capabilities to ensure that messages are routed among the correct elements in a network. [00117] In an implementation, the CRBT (314) is a value-added service that allows customization of the ring back tone. When a call is placed, the caller may hear an audible alert through his or her device. The MRF (316) is a carrier-class product for service providers virtualizing their networks. The MRF (316) provides media services like announcements, tones, and conferencing for VoLTE, Wi-Fi calling, and fixed voice-over Internet protocol (VoIP) solutions. The EMS (318) may manage specific types of one or more network elements within a telecommunication management network. The OSS/BSS (320) may be a collection of hardware and software tools designed to help organizations monitor, analyze, and manage telecom networks. For example, the OSS/BSS (320) may include components that a telecommunications service provider uses to run its business operations toward customers. The load balancer (322) provides service providers with comprehensive 5G security solutions to protect networks from core to far edge, defending against sophisticated fraud and abuse. The EMS (318) connects users, computers, and related devices across departments, facilitating access to data and business insights. [00118] According to an implementation, the system components of the system architecture (300A) may communicate via different protocols including, but not limited to, a diameter protocol, a SIP protocol, a representational state transfer (REST) protocol, and a media sessions markup language (MSML) protocol. The diameter protocol is a next-generation industry-standard protocol that exchanges authentication, authorization, and accounting (AAA) information in long-term evolution (LTE) and IMS networks. The SIP protocol is a signaling protocol that enables VoIP by defining the messages sent between endpoints and managing the actual elements of a call. The SIP protocol supports voice calls, video conferencing, instant/messaging, and media distribution. The REST protocol is a protocol that imposes certain constraints to be satisfied by an API. The MSML protocol controls and invokes many different types of services on IP media servers. [00119] Although FIG. 3A shows exemplary components of the system architecture (300A), in other embodiments, the system architecture (300A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 3A. Additionally, or alternatively, one or more components of the system architecture (300A) may perform functions described as being performed by one or more other components of the system architecture (300A). [00120] FIG. 3B illustrates another exemplary system architecture (300B) for implementing for implementing the system (108), in accordance with an embodiment of the present disclosure. [00121] Referring to FIG. 3B, the TAS unit (330) is configured to perform a “request-a-call-back” service. [00122] As shown in FIG. 3B, the system architecture (300B) includes the TAS unit (330), an Evolved Packet System (EPS) (323), common API framework (CAPIF) (350), an adaptive troubleshooting and operations management (ATOM) platform (352), charging function (CHF) (354), subscription engine (356), fulfillment management system (FMS) (358), unified inventory manager (360), and market place and self-care portal (362). The system architecture (300B) may also include an EDGE load balancer (not shown). [00123] In an implementation, the CAPIF (350) is a network layer API, enabling abstraction and orchestration capability. It is a platform that exposes network capabilities as Restful APIs. The ATOM platform (352) is a cloud-native data lake platform tailored for carriers to enable smarter operations through machine learning (ML). The ATOM platform (352) leverages machine learning to detect anomalous network patterns and create reports and alerts based on these patterns for proactive root cause analysis and resolution before the network symptoms start affecting operations. The CHF (354) is responsible for completing the billing function. The subscription engine (356) is an e-commerce portal that manages digital offer catalog and pricing, subscription management, billing, revenue recognition and quoting. The FMS (358) is a workflow orchestration, provisioning and activation platform that simplifies operations by replacing a traditional, high-touch management model with a next-generation, programmable and virtualized model. The unified inventory manager (360) stores the logical and physical inventory data of every asset, device, node, and application, including active and passive devices. All touch points in the network that need to provision or query the inventory data for enrichment have an interaction with the unified inventory manager (360). [00124] According to an implementation, the TAS unit (330) may maintain a queue for each time slot as per service provider requirements. In an example, there may be N number of time slots. For instance, a day may be divided into 15-minute time slots. For example, for time slot 11 AM to 11:15 AM, the TAS unit (330) may maintain one queue (referred to as the first queue), and for time slot 11:15 AM to 11:30 AM, the TAS unit (330) may maintain another queue (referred to as second queue). In an implementation, the time slots may be configurable as per service provider requirements. [00125] In an implementation, the TAS unit (330) may receive a call-back request from a user (102). For example, the call-back request may include call-back data. For example, the call-back data may include a preferred time or preferred time slot provided by the user (102) for call-back. In an example, the preferred time provided by the user (102) may be 11:20 AM. According to an implementation, the TAS unit (330) may store the call-back request in a queue maintained for a time slot in which the preferred time falls. For instance, if the preferred time provided by the user (102) is 11:20 AM, then the TAS unit (330) may store the call-back request received from the user (102) in the second queue. Further, the call-back data is stored in the database (210) (e.g., system-shared memory). [00126] In an aspect, the call-back data is check-pointed to the mate process. The call-back data corresponding to the call-back request is checkpointed to store the status of the call-back request, ensuring that the call-back is performed within the preferred time. This ensures the call-back happens during the time period that the user (102) prefers. Accordingly, in case of system restart or process failover, the call-back data is not lost (i.e., there is call-back data retention). The call-back data can be retrieved from the database (210) in case of system restart or process failover. This ensures continuity and consistency of the call-back operations even if the any interruptions or failures occur. [00127] In an implementation, the TAS unit (330) may continuously execute a system cyclic timer to scan each queue as per the current time. For instance, the system cyclic timer may be triggered after each 15 minutes. According to an implementation, if the current time is 10:55 AM, the system cyclic timer will be triggered at 11:00 AM and then at 11:15 AM if the configured time slot is 15 minutes. For instance, the TAS unit (330) may scan the first queue that is scheduled for 11:00 AM to 11:15 AM time period and pick out all the calls scheduled between 11:00 AM to 11:15 AM tim¬e period. The TAS unit (330) may then scan the second queue that is scheduled for 11:15 AM to 11:30 AM time period and pick out all the calls scheduled between 11:15 AM to 11:30 AM time period. In an implementation, the TAS unit (330) will start picking out or popping out calls one by one from each queue and will try to patch the call to the respective users. [00128] According to an implementation, the TAS unit (330) may obtain or pick out the call-back request from the second queue and patch a call for the user (102) with an agent as per the preferred time of the user (102). Accordingly, multiple system cyclic timers are not required to be executed (i.e., it is not required to run a system cyclic timer for each user (102)). In an implementation, there may be some failed calls. According to an implementation, the TAS unit (330) may execute a retry cyclic timer to scan a list of failed calls and re-attempt the failed calls for a configured number of times before marking the calls as failed. Execution of the retry cyclic time provides a maximum call completion rate. [00129] In an aspect, the TAS unit (330) executes the call-back based on the preferred time provided in the call-back request. If the call-back fails due to network issues, system errors, or other transient problems, the retry cyclic timer initiates a retry process. The TAS unit (330) schedules retry attempts using the retry cyclic timer. The retry cyclic timer triggers at regular intervals to reattempt the call-back execution. The call-back request is scheduled for 3:00 PM. At that time, the TAS unit (330) attempts to make the call but encounters an error (e.g., the line is busy, or the call fails due to a network issue). The TAS unit (330) sets a retry cyclic timer to attempt the call-back again in 5 minutes. If the retry also fails, the TAS unit (330) schedules additional retries at 5-minute intervals. The system (108) may be configured with a retry limit, such as a maximum of 10 retries. [00130] Although FIG. 3B shows exemplary components of the system architecture (300B), in other embodiments, the system architecture (300B) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 3B. Additionally, or alternatively, one or more components of the system architecture (300B) may perform functions described as being performed by one or more other components of the system architecture (300B). [00131] FIG. 4 illustrates an exemplary flow diagram (400) describing “request-a-call-back” service, in accordance with an embodiment of the present disclosure. [00132] In an implementation, the entities that carry out the flow diagram (400) include the CAPIF (350), the TAS unit (330), the MRF (316), the customer care (402), an interconnection border control function (IBCF) (404), the customer (102), and the CHF (354). In an example, the customer (102) may be a user of the user equipment (104). [00133] At step (408) of the flow diagram (400), the CAPIF (350) sends “Request A Callback application programming interface (API) hypertext transfer protocol (HTTP)” to the TAS unit (330). The “Request A Callback API (HTTP)” allows applications to request the call-back or to schedule the call-back operation over HTTP. [00134] At step (410) of the flow diagram (400), the TAS unit (330) sends “200 OK (HTTP)” to the CAPIF (350). Upon receiving the “Request A Callback API (HTTP)” from the CAPIF (350), the TAS unit (330) sends the “200 OK (HTTP)” to the CAPIF (350) to confirm reception of the “Request A Callback API (HTTP)”. [00135] Block (411) describes time-based trigger information. In an aspect, the time-based trigger information comprises call-back time preference (e.g., date (DD-MM-YYYY) and time (HH-MM-SS), etc.). The “200 OK (HTTP)” is an HTTP status code that indicates that the server has successfully processed the call-back request. [00136] At step (412) of the flow diagram (400), the TAS unit (330) sends “INVITE (w/o SDP)” to the MRF (316). The INVITE request without (session description protocol) SDP is an initial INVITE message that does not include SDP information. The INVITE is used to initiate a communication session or invite participants to a session. The SDP includes multimedia communication sessions, including details like media types (audio, video), codecs, network information, and session attributes. [00137] At step (414) of the flow diagram (400), the MRF (316) sends “200 OK (SDP-MRF)” to the TAS unit (330). The 200 OK (SDP-MRF) refers to an HTTP response indicating that a request involving SDP (Session Description Protocol) has been successfully processed by the server with the media resource functions (MRF). The response includes SDP information relevant to media handling. [00138] A customer contact record (CCR)/a customer contact archive (CCA) (Service-Specific-Info AVP: