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 MANAGING SERVICE REQUESTS IN A NETWORK

2. APPLICANT(S)
Name Nationality Address
JIO PLATFORMS LIMITED INDIAN Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 360006, 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 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.
TECHNICAL FIELD
[0002] The present disclosure relates generally to wireless communication systems. More particularly, the present disclosure relates to a system and a method for managing one or more service requests in a network.
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 ‘IP Multimedia Subsystem (IMS) Network’ used hereinafter in the specification refers to a standard architecture for delivering IP-based multimedia services such as voice over Internet Protocol (VoIP), video calls, messaging, and conferencing. IMS provides a framework for delivering services over both fixed and mobile networks using Session Initiation Protocol (SIP) signaling.
[0005] The expression ‘Telephony Application Server (TAS)’ used hereinafter in the specification refers to an application server that hosts telephony services for enterprise customers, allowing for advanced telephony features such as click-to-call, ad-hoc conferencing, and virtual mobile number services. The TAS interfaces with the IMS network and other network functions to manage telephony applications and communications.
[0006] The expression ‘Common Application Programming Interface Framework (CAPIF)’ used hereinafter in the specification refers to a standard framework for exposing network services and functionalities via Application Programming Interfaces (APIs). The CAPIF facilitates interaction between different network functions and services by ensuring secure, scalable, and interoperable API communication, enabling service requests like Representational State Transfer (REST)-based communication between application servers and network functions.
[0007] The expression ‘Elastic Load Balancing (ELB)’ used hereinafter in the specification refers to a service that automatically distributes incoming traffic (e.g., one or more service requests) across multiple servers to ensure optimal resource utilization, fault tolerance, and high availability. The ELB is commonly used in cloud environments to balance traffic across application instances.
[0008] The expression ‘Call Session Control Function (CSCF)’ used hereinafter in the specification refers to a function within the IMS network that manages Session Initiation Protocol (SIP) signaling for session management, including call control, registration, and routing of multimedia services for users.
[0009] The expression ‘Multimedia Resource Function (MRF)’ used hereinafter in the specification refers to a function within the IMS architecture that provides media-related services such as mixing, transcoding, and recording for real-time communication sessions like voice, video, and conferencing.
[0010] The expression ‘Mobile Number Portability (MNP)’ used hereinafter in the specification refers to a functionality in a telecommunication network that enables users to retain their mobile number when switching from one service provider to another. This ensures seamless service continuity without the need to change phone numbers.
[0011] The expression ‘Charging Function (CHF)’ used hereinafter in the specification refers to a network function responsible for charging management in a 5G network. The CHF collects usage data from other network functions and applies appropriate charging policies for real-time billing and quota management for users and services.
[0012] The expression ‘Adaptive Troubleshooting and Operations Management Platform (ATOM)’ used hereinafter in the specification refers to a platform that provides intelligent and adaptive troubleshooting capabilities for network operations. ATOM uses data analytics and real-time monitoring to detect, analyze, and resolve network issues, thereby improving operational efficiency and reducing downtime.
[0013] The expression ‘Enterprise Provisioning Server (EPS)’ used hereinafter in the specification refers to a system responsible for provisioning and managing enterprise services and resources. The EPS automates the assignment of services like Internet Protocol (IP) telephony, bandwidth allocation, and security features for enterprise customers.
[0014] The expression ‘Self Care Portal and Market Place’ used hereinafter in the specification refers to an online platform that allows end-users to manage their services, configurations, and subscriptions autonomously. Users can access a marketplace to explore and subscribe to new services offered by the service provider.
[0015] The expression ‘Fulfillment Management System (FMS)’ used hereinafter in the specification refers to a system responsible for ensuring that service requests are properly executed within a telecommunications network. The FMS manages the workflow of service requests, including order processing, provisioning, and activation of requested services.
[0016] The expression 'SIP' used hereinafter in the specification refers to a Session Initiation Protocol. The SIP is a signaling protocol used to establish, maintain, and terminate real-time communication sessions over IP networks. SIP is widely utilized in voice over IP (VoIP), video conferencing, and other multimedia communication applications.
[0017] The expression ‘DRA’ used hereinafter in the specification refers to a Diameter Routing Agent. The DRA is a network component used in Diameter-based systems to manage and route Diameter messages between nodes in a telecommunications network. Diameter is a protocol used for authentication, authorization, and accounting (AAA) in network environments.
[0018] The expression ‘CRBT’ used hereinafter in the specification refers to Caller Ringback Tones. The CRBT are personalized audio tones that a caller hears while waiting for their call to be answered, replacing the standard ringing sound with music, messages, or other content chosen by the call recipient.
[0019] The expression ‘OSS’ used hereinafter in the specification refers to an Operational Support System. The OSS is a comprehensive framework used for managing, controlling, and optimizing telecommunications network operations and services, including provisioning, fault management, and performance monitoring.
[0020] The expression ‘BSS’ used hereinafter in the specification refers to a Business Support System. The BSS is 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.
[0021] The expression ‘Configurable Hypertext Transfer Protocol (HTTP) Interface or multi-threaded Interface’ used hereinafter in the specification refers to an interface capable of handling multiple concurrent operations or service requests based on the HTTP protocol by utilizing multiple threads (e.g., first thread and second thread). The HTTP interface allows for parallel processing of incoming and outgoing service requests, enabling more efficient resource utilization and faster response times when interacting with different network functions or components. The configurable HTTP interface allows for the dynamic configuration of API-based service requests and responses, enabling support for various network services and functionalities, including RESTful service interactions, through flexible HTTP-based communication.
[0022] The expression ‘Toll-Free Number (TFN)’ used hereinafter in the specification refers to a telephone number that allows callers to reach a business or service provider without incurring any charges. The cost of the call is borne by the recipient of the call, typically a business. TFNs are commonly used for customer service, support, and business inquiries. In telecommunication systems, TFNs can be used to enable click-to-call services, callback requests, or other forms of voice communication between the user and the service provider.
[0023] The expression ‘Interactive Voice Response (IVR)’ used hereinafter in the specification refers to an automated telephony system that interacts with callers through voice or touch-tone keypad inputs. IVR systems enable users to retrieve or provide information without human intervention by using pre-recorded voice prompts and input recognition. IVR is widely used in customer support systems, allowing users to interact with self-service options or route their call to the appropriate department. In services like callback or ad-hoc conferencing, IVR may guide users through call setup processes.
[0024] The expression ‘In-Building Solution (IBS)’ used hereinafter in the specification refers to a telecommunication infrastructure designed to enhance mobile network coverage within buildings, including offices, malls, and residential complexes. The IBS ensures that users have uninterrupted connectivity for voice and data services in areas where outdoor signal strength may be weak. For services like the click-to-call or callback, The IBS enables seamless communication by maintaining strong network coverage, especially in large or enclosed spaces.
[0025] The expression ‘Virtual Mobile Network (VMN)’ used hereinafter in the specification refers to a telecommunications service where a provider offers mobile network services without owning the network infrastructure. The VMNs are leasing capacity from established mobile network operators (MNOs) to deliver voice, messaging, and data services to their users. In callback and click-to-call systems, the VMNs allow users to access mobile services, providing flexibility and cost-effectiveness without the need for physical network infrastructure.
BACKGROUND
[0026] 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.
[0027] Wireless communication technology has rapidly evolved over the past few decades. The first generation of wireless communication technology was analog, offering only voice services. Further, text messaging and data services became possible when the second-generation (2G) technology 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 the wireless communication with faster data speeds, improved network coverage, and security. Currently, fifth generation (5G) technology is being deployed, offering significantly faster data speeds, lower latency, and the ability to connect many devices simultaneously. These advancements represent a significant leap forward from previous generations, enabling enhanced mobile broadband, improved Internet of Things (IoT) connectivity, and more efficient use of network resources. The sixth generation (6G) technology promises to build upon these advancements, pushing the boundaries of wireless communication even further. While the 5G technology is still being rolled out globally, research and development into the 6G are rapidly progressing, with the aim of revolutionizing the way to connect and interact with technology.
[0028] The conventional system architecture for providing network-related services include interfaces between various network elements that are unorganized, rigid, and non-configurable. These network interfaces fail to cope with the different network elements present in the network. As a result, the network interfaces limit the ability of the network to effectively manage and deliver different services, such as click-to-call, virtual mobile numbers, or ad-hoc conferencing. Additionally, the rigidity of the existing interfaces complicates efforts to upgrade or modify the architecture, which may lead to unpredictable behavior and potential service disruptions. This lack of flexibility in the current architecture hampers network optimization, leading to inefficient use of resources and suboptimal customer experiences, especially in the context of complex service management.
[0029] There is, therefore, a need in the art to provide a system and method to overcome the problems associated with the prior arts.
SUMMARY
[0030] In an exemplary embodiment, a method for managing one or more service requests in a network is disclosed. The method includes receiving, by a server, at least one service request from a User Equipment (UE) using a Common Application Programming Interface Framework (CAPIF) and over a communication interface. The method further includes analyzing, by the server, the at least one received service request to identify at least one network function associated with the server. The method further includes transmitting, by the server, the at least one received service request towards the at least one network function to trigger at least one service.
[0031] In an embodiment, the method further includes processing, by the at least one network function, the at least one received service request, and triggering, by the at least one network function, the at least one service corresponding to the at least one received service request based on the processing.
[0032] In an embodiment, the method further includes receiving, by the server, at least one triggered service from the at least one identified network function, and forwarding, by the server, the at least one triggered service towards the UE using the CAPIF (116) over the communication interface.
[0033] In an embodiment, the at least one service request corresponds to a Hypertext Transfer Protocol (HTTP) based Representational State Transfer (REST) request.
[0034] In an embodiment, the communication interface corresponds to a hypertext transfer protocol (HTTP) interface, and the server corresponds to a Telephony Application Server (TAS).
[0035] In an embodiment, the at least one network function comprises one or more of: a Media Resource Function (MRF), a Mobile Number Portability (MNP), and a Charging Function (CHF), an Adaptive Troubleshooting and Operations Management Platform (ATOM), and a Call Session Control Function (CFX).
[0036] In an embodiment, the method further includes establishing at least one first thread and at least one second thread between the server and the CAPIF respectively to manage the at least one received service request. The at least one first thread is configured to receive the at least one service request from the CAPIF and forward to the server. The at least one second thread is configured to transmit the at least one triggered service from the server to the CAPIF.
[0037] In another exemplary embodiment, a system for managing one or more service requests in a network is disclosed. The system includes a memory and a processing unit. The processing unit is coupled with the memory to execute a set of instructions stored in the memory. The processing unit is configured to receive at least one service request from a User Equipment (UE) using a Common Application Programming Interface Framework (CAPIF) over a communication interface. The processing unit is configured to analyze the at least one received service request to identify at least one network function associated with the server. The processing engine is further configured to transmit the at least one received service request towards the at least one network function to trigger at least one service.
[0038] In an exemplary embodiment, the present disclosure relates to a user equipment (UE) communicatively coupled with a network. The coupling includes steps of receiving, by the network, a connection request from the 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 UE is configured to generate at least one service request. The at least one service request is managed in the network by a method that includes receiving, by a server, at least one service request from a User Equipment (UE) using a Common Application Programming Interface Framework (CAPIF) and over a communication interface. The method further includes analyzing, by the server, the at least one received service request to identify at least one network function associated with the server. The method further includes transmitting, by the server, the at least one received service request towards the at least one network function to trigger at least one service.
[0039] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.
OBJECTIVES OF THE PRESENT DISCLOSURE
[0040] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows.
[0041] An objective of the present disclosure is to manage one or more service requests in a network.
[0042] Another objective of the present disclosure is to provide a hypertext transfer protocol (HTTP) interface (e.g., configurable HTTP interface) that facilitates the interaction between a Telephony Application Server (TAS) and the Common Application Programming Interface framework (CAPIF) for delivering various network services, such as click-to-call, virtual mobile numbers, and ad-hoc conferencing.
[0043] Another objective of the present disclosure is to enable efficient and seamless transmission of an HTTP Representational State Transfer (REST) request between various network functions, ensuring smooth and flexible service management.
[0044] An objective of the present disclosure is to provide a multi-threaded interface between the TAS and CAPIF to separate the processes for receiving and sending the service request, improving network efficiency, scalability, and performance.
[0045] 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
[0046] 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.
[0047] FIG. 1A illustrates an exemplary network architecture for implementing a system for managing one or more service requests in a network, in accordance with an embodiment of the present disclosure.
[0048] FIG. 1B illustrates an exemplary system architecture for managing the one or more service requests in the network, in accordance with an embodiment of the present disclosure.
[0049] FIG. 2 illustrates an exemplary block diagram of the system for managing the one or more service requests in the network, in accordance with an embodiment of the present disclosure.
[0050] FIG. 3 illustrates another exemplary system architecture for managing the one or more service requests in the network, in accordance with an embodiment of the present disclosure.
[0051] FIG. 4 illustrates an exemplary flow diagram of a method for managing the one or more service requests in the network, in accordance with an embodiment of the present disclosure,
[0052] FIG. 5 illustrates a computer system in which or with which the embodiments of the present disclosure may be implemented.
[0053] The foregoing shall be more apparent from the following more detailed description of the disclosure.
LIST OF REFERENCE NUMERALS
100A - Network Architecture
102-1, 102-2…102-N – Plurality of Users
104-1, 104-2…104-N – Plurality of User Equipments
106 – Network
108 – System
100B – System Architecture
110 - Web portal services
112 - User Device
114 - Elastic Load Balancing (ELB)
116 - Common Application Programming Interface Framework (CAPIF)
118 - Call Session Control Function (CFX)
120 - Multimedia Resource Function (MRF)
122 - Mobile Number Portability (MNP)
124 - Charging Function (CHF)
126 - Adaptive Troubleshooting and Operations Management Platform (ATOM)
128, 322 - Telephony Application Server (TAS)
130 - Enterprise Provisioning Server (EPS)
132 - Self Care Portal And Market Place
134 - Fulfillment Management System (FMS)
136 - Subscription Engine
200 – Block Diagram
202 – Memory
204 – Plurality of Interfaces
206 – Processing unit
208 – Receiving unit
210 – Interfacing unit
212 – Database
300 - System Architecture
302 – User equipment (UE)
304 – Internet protocol (IP) Multimedia Subsystem (IMS)
306 – Mobile number portability (MNP)
308 – Online charging system (OCS)
310 – Diameter routing agent (DRA)
312 – Caller ring back tones (CRBT)
314 – Media resource function (MRF)
316 – Element management system (EMS)
318 – Operational support system (OSS) / Business support system (BSS)
320 – Load balancer
324 – Provisioning server
400 – Flow Diagram
500 – Computer System
510 – External Storage Device
520 – Bus
530 – Main Memory
540 – Read-Only Memory
550 – Mass Storage Device
560 – Communication Ports
570 – Processor
DETAILED DESCRIPTION
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] Further, the user device may also comprise a “processor” or “processing engine” includes processing engine, 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.
[0063] 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), and now Fifth Generation (5G), and more such generations are expected to continue in the forthcoming time.
[0064] 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 GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), LTE (Long-Term Evolution), and 5G. 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.
[0065] As wireless technologies are advancing, there is a need to cope with the 5G requirements and deliver a high level of network service to customers. Further, there is a requirement to provide quick solutions related to any issue faced by the network customers. For example, the existing techniques use various network interfaces that communicate with the different network elements, such as a common application programming interface framework (CAPIF) and a Telephony Application Server (TAS) to fulfill the requirements of a network customer. However, the network interfaces of the existing techniques are unorganized, rigid, and non-configurable. Further, the network interfaces face compatibility issues with various network elements present in the network. Thus, the existing system architecture that uses these network interfaces fails to perform optimally in providing different network services to the network customers. Further, modifying the existing interfaces can lead to unpredictable behavior of a network resource.
[0066] Hence, there is a need for an improved system architecture that uses network interfaces that are configurable and easy to integrate with the different network elements present in the network and provides various network services to the customers optimally.
[0067] The present disclosure aims to overcome the above-mentioned and other existing problems in this field of technology by disclosing a configurable Hypertext Transfer Protocol (HTTP) interface (e.g., a multi-threaded interface) that provides an integration between the CAPIF and TAS for managing one or more service requests (e.g., HTTP based Representational State Transfer (REST) request). The configurable HTTP) Interface or multi-threaded Interface refers to an interface capable of handling multiple concurrent operations or service requests based on the HTTP protocol by utilizing multiple threads (e.g., first thread and second thread). The HTTP interface allows for parallel processing of incoming and outgoing service requests, enabling more efficient resource utilization and faster response times when interacting with different network functions or components. The configurable HTTP interface allows for the dynamic configuration of Application Programming Interface (API)-based service requests and responses, enabling support for various network services and functionalities, including RESTful service interactions, through flexible HTTP-based communication.
[0068] The HTTP interface supports features like configuring the number of threads that handle incoming requests, allowing for multi-threaded operations. This means multiple requests can be processed simultaneously, enhancing the performance, scalability, and responsiveness of the system. The interface utilizes HTTP, a widely used protocol in web communications. The HTTP is used to structure and transmit messages (requests and responses) between the CAPIF and the TAS. The HTTP interface bridges the CAPIF and TAS, which handles telephony-related services like voice, messaging, and multimedia communications. Further, the HTTP interface manages various service requests, such as initiating a call, sending a message, or handling multimedia resources. These service requests are sent using HTTP-based Representational State Transfer (REST). In an embodiment, the REST is a style of web service architecture that uses simple HTTP methods (e.g., GET, POST, PUT, or DELETE) to perform operations. The REST is widely used in APIs because it is easy to implement and scalable. For example, when a User Equipment (UE) requests a service from the TAS, the service request is sent as an HTTP REST request (such as a POST or GET request). The HTTP interface processes this request, forwards it to the network function in the TAS, and then manages the response. The multi-threaded functionality allows the HTTP interface to process multiple service requests concurrently. This functionality is particularly useful in environments with high traffic where many users or devices are sending service requests at the same time. By handling several threads (or requests) simultaneously, the present disclosure improves performance, ensuring timely responses.
[0069] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.
[0070] FIG. 1A illustrates an exemplary network architecture (100A) for implementing a system (108) for managing the one or more service request in a network (106), in accordance with an embodiment of the present disclosure.
[0071] As illustrated in FIG. 1A, the network architecture (100A) 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 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 be collectively referred to as the UE (104). Although only three UE (104) are depicted in FIG. 1A, however, any number of the UE (104) may be included without departing from the scope of the ongoing description.
[0072] 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.
[0073] 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.
[0074] Referring to FIG. 1A, the UE (104) may communicate with the system (108) through the 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 (100A) 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.
[0075] 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.
[0076] In an embodiment, the UE (104) is communicatively coupled with the network (106). The network (106) may receive a connection request from the UE (104). The network (106) 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.
[0077] Although FIG. 1A shows exemplary components of the network architecture (100A), in other embodiments, the network architecture (100A) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1A. Additionally, or alternatively, one or more components of the network architecture (100A) may perform functions described as being performed by one or more other components of the network architecture (100A).
[0078] FIG. 1B illustrates an exemplary system architecture (100B) for managing the one or more service requests in the network (106), in accordance with an embodiment of the present disclosure.
[0079] As shown in FIG. 1B, the TAS (128) may receive at least one service request from the UE (also referred to as user devices (112)). In other words, a user may interact with a web portal through the UE to initiate the at least one service request. In an aspect, the at least one service request may include, but is not limited to, a click-to-call request, a request for callback, and an Ad-hoc conference request. The service request may utilize one or more technologies, such as toll-free numbers (TFN), interactive voice response (IVR) systems, in-building solutions (IBS), or virtual mobile networks (VMN) to facilitate the requested services. For example, the UE may use the TFN or IVR to interact with the system while initiating the click-to-call or callback service, ensuring efficient communication and service delivery. In an aspect, the TAS (128) may communicate with a plurality of network elements such as a call session control function (CFX) (118), a multimedia resource function (MRF) (120), a mobile number portability (MNP) (122), a charging function (CHF) (124), an adaptive troubleshooting and operations management platform (ATOM) (126), an enterprise provisioning server (EPS) (130), and the CAPIF (116) to provide the services requested by the UE.
[0080] In an aspect, the CFX (118) is responsible for managing and controlling voice or multimedia communication sessions in the network, especially within the IP Multimedia Subsystem (IMS). It handles signaling between the user and the network, allowing calls to be set up, maintained, and terminated. This function crucial in voice over IP (VoIP) services. The MRF (120) is used to provide media-related services, such as conferencing, media mixing, and IVR. It handles multimedia resources in the network and enables media services like tones, announcements, and media processing for calls. The MNP (122) is a function that allows users to retain their mobile phone numbers when switching from one service provider to another. The MNP (122) function ensures that the correct routing of calls and messages occurs even after the number is ported to a new operator, providing a seamless experience for users. The CHF (124) handles the billing and charging aspects of telecommunications services. It collects usage data and calculates charges for voice, data, and multimedia services. The CHF communicates with Online Charging Systems (OCS) to manage real-time usage-based billing, ensuring proper revenue management. The ATOM (126) is a platform used for monitoring, troubleshooting, and managing network operations. It provides advanced analytics, fault detection, and performance management to optimize network services. The ATOM (126) may detect issues and trigger corrective actions to ensure service quality and continuity.
[0081] In an aspect, the EPS (130) is responsible for provisioning and managing services for enterprise customers. It handles tasks such as activating, deactivating, and configuring services for business users, ensuring that the telecommunication services are correctly set up and maintained according to customer requirements. The EPS (130) communicates with the CAPIF (116) through a fulfillment management system (FMS) (134). In an aspect, the FMS (134) platform communicates with different network elements such as a self-care portal and marketplace (132), and a subscription engine (136) for monitoring trouble tickets, work orders, and workflows using an intuitive graphical user interface. The self-care portal and marketplace (132) is an online platform that allows end-users to manage their services, configurations, and subscriptions autonomously. The users can access a marketplace to explore and subscribe to new services offered by the service provider. Additionally, the subscription engine (136) may be integrated with billing systems, user profiles, and service management platforms to provide end-to-end management of subscriber plans and services.
[0082] In an aspect, an elastic load balancing (ELB) (114) communicates with different web portal services (110) such as click-to-call service, request a call back service, virtual mobile number service, ad-hoc conference service, and the like. The click-to-call service allows users to initiate a call by clicking on a web browser or mobile application button. In the request for callback service, the system automatically calls back the user based on predefined conditions (e.g., user availability, unsuccessful call attempts, missed call notifications, or user preferred schedule to call). The virtual mobile number service allows the users to assign temporary or alternate phone numbers. The ad-hoc conference service enables on-demand conference calls. The ELB (114) automatically distributes the incoming service requests related to the various web portal services (110) across multiple targets, such as, containers, and IP addresses, in various available network functions. In an aspect, the ELB (114) communicates with the TAS (128) through the CAPIF (116). The CAPIF (116) allows secure exposure of 5G core application programming interface (API) to third-party domains and also enables third parties to define and expose their own API. The CAPIF (116) enables different network functions to communicate with the TAS (128), allowing the TAS (128) to access different services efficiently based on a user request. Further, handling multiple user service requests from various web portal services (e.g., click-to-call, request for callback, ad-hoc conference, etc.) poses a challenge in terms of distributing the service requests efficiently to different network functions. Moreover, securely exposing APIs while managing communication between network functions and the TAS through the CAPIF introduces latency and security concerns.
[0083] The present disclosure proposes an interface (e.g., the configurable HTTP interface) between the CAPIF (116) and the TAS (128) to address the problems related to the service requests and API communication in a more efficient and secure manner. The present disclosure enables seamless communication between the TAS (128) and the CAPIF (116) through the configurable HTTP interface, ensuring that different network functions can interact effectively with the TAS (128), allowing the TAS (128) to access and manage various services based on the user request. The configurable HTTP interface ensures smoother, faster, and more secure processing of service requests while minimizing communication delays and potential security risks associated with the API exposure.
[0084] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for managing the one or more service requests in the network (106), in accordance with an embodiment of the present disclosure. The network (106) may correspond to the telecommunication network. Examples of the network include the 4G network, the 5G network, the 6G network, and the like.
[0085] The system (108) includes one or more processor(s) or a processing unit (206). The one or more processor(s) 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, one or more processor(s) may be configured to fetch and execute computer-readable instructions stored in a memory (202) of the system (108). The memory (202) 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 (202) may comprise any non-transitory storage device including, for example, a volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read-Only Memory (EPROM), a flash memory, and the like.
[0086] In an embodiment, the system (108) may include an interface(s) (204). The interface(s) (204) 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) (204) may facilitate communication through the system (108). The interface(s) (204) 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, the processing unit (206) and a database (212). The processing unit (206) may further include a receiving unit (208) and an interfacing unit (210).
[0087] In an embodiment, the processing unit (206) may be implemented as a combination of a hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing unit (206). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing unit (206) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing unit (206) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the processing unit (206). In such examples, the system (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (108) and the processing resource. In other examples, the processing unit (206) may be implemented by electronic circuitry.
[0088] In an embodiment, the processing unit (206) may be configured to fetch and execute computer-readable instructions stored in the memory (202). The processing unit (206) may be configured to execute a sequence of instructions for managing the one or more requests, which may be embodied in a program or software. The instructions can be directed to the processing unit (206), which may subsequently program or otherwise be configured to implement the methods of the present disclosure. In some examples, the processing unit (206) is configured to control and/or communicate with large databases, perform high-volume transaction processing, and generate reports from large databases. The processing unit (206) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions.
[0089] To manage the one or more service requests, the receiving unit (208) may initially receive at least one service request from the UE (104) using the CAPIF (116) and over a communication interface. In an aspect, to receive the at least one service request the receiving unit (208) may use a protocol, such as an HTTP REST protocol, or a Session Initiation Protocol (SIP). Additionally, the data within the service request may be structured in formats such as JavaScript Object Notation (JSON) or eXtensible Markup Language (XML) formats, which are commonly used for representing the content of the service request.
[0090] The HTTP REST protocol is used for transmitting data over the web using simple HTTP requests (GET, POST, PUT, DELETE) between client and server. The SIP is used primarily for signaling in voice over IP (VoIP) and multimedia services. The JSON or XML may be used to represent the data in a structured format within the request.
[0091] In some embodiments, the processing unit (206) may communicatively couple to a server (e.g., the TAS 128) via the network (106) to receive the at least one service request from the UE (104). In an embodiment, the at least one service request may include, but is not limited to, a click-to-call request, a request for callback, and an Ad-hoc conference request. The service request may utilize one or more technologies, such as toll-free numbers (TFN), interactive voice response (IVR) systems, in-building solutions (IBS), or virtual mobile networks (VMN) to facilitate the requested services. For example, the UE may use the TFN or IVR to interact with the system (108) while initiating the click-to-call or callback service, ensuring efficient communication and service delivery.
[0092] In an embodiment, the interfacing unit (210) may be configured to provide the communication interface between the CAPIF (116) and the TAS (128). The communication interface is configurable and supports flexible service interaction. Specifically, it may be a configurable HTTP interface or a multi-threaded interface. The configurable HTTP interface means that the communication between the TAS and CAPIF can be modified to specific customer needs, allowing different configurations and protocols. Meanwhile, a multi-threaded interface ensures efficient handling of multiple service requests simultaneously, optimizing performance by allowing parallel execution of service requests. The configurable HTTP interface improves scalability and responsiveness, making the system robust in handling high-volume service requests.
[0093] After receiving a service request, the processing unit (206) may further analyze the at least one received service request to identify at least one network function associated with the server. To further elaborate, in order to analyze the at least one received service request, the processing unit (206) may examine specific metadata associated with the request, such as the type of service, the user identifier (ID), session parameters, and the requested action. This analysis is conducted by extracting information from the service request headers and payload, which helps to identify the network function required to fulfill the service request.
[0094] For example, the processing unit (206) may inspect the service type (e.g., the click-to-call or callback service) and match it against a predefined mapping of network functions that are capable of handling the particular service. The processing unit (206) may also evaluate additional conditions such as user availability, current network load, and location-based preferences to identify the most optimal network function to transmit the service request. The evaluation is facilitated through a set of decision-making algorithms and policies configured within the processing unit (206), which may utilize look-up tables, heuristic methods, or rule-based systems to accurately map service requests to corresponding network functions.
[0095] The at least one network function may include one or more of a Media Resource Function (MRF), a Mobile Number Portability (MNP), a Charging Function (CHF), an Adaptive Troubleshooting and Operations Management Platform (ATOM), and a Call Session Control Function (CFX).
[0096] The MRF is responsible for media processing tasks such as conferencing and transcoding. The MNP allows users to retain mobile numbers while switching between service providers. Further, the CHF manages billing and charging for services the UE uses. Further, the ATOM oversees diagnostics and issue resolution within the network. Further, the CFX manages session-based communication services, like voice calls and multimedia sessions.
[0097] The processing unit (206) may further transmit the at least one received service request towards the at least one network function to trigger at least one service. In an embodiment, the at least one service corresponding to the at least one received service request may include one of a click-to-call service, a request for callback service, a virtual mobile number service, or an ad-hoc conference service. The click-to-call service allows users to initiate a call by clicking on a web browser or mobile application button. The request for callback service, where the system automatically calls back the user based on certain conditions. The virtual mobile number service allows the users to assign temporary or alternate phone numbers. The ad-hoc conference service enables on-demand conference calls.
[0098] In an aspect, the term ‘trigger’ refers to the initiation or activation of a specific action within the network function in response to the service request. Upon receiving the service request, the processing unit (206) sends the relevant information (such as user credentials and service type) to the network function responsible for delivering the requested service. For example, if the service request is for a click-to-call service, the processing unit (206) triggers the call setup process by communicating with the TAS (128), establishing the voice call between the user and the destination party. In the case of a request for a callback service, the trigger initiates a sequence where the system attempts to call the user back based on predefined conditions (such as user availability or missed calls)
[0099] In some embodiments, the at least one network function may process the at least one received service request. For example, if the service request is a click-to-call request, the network function may process the service request by verifying the user's identity, ensuring that the necessary resources (e.g., available network bandwidth or call slots) are available, and initiating the signaling required to establish a call session with the destination party. The processing may also include executing any predefined business logic, such as checking for specific rules (e.g., user restrictions, service availability) before proceeding with the service. Based on the processing, the at least one network function may trigger the at least one service corresponding to the at least one received service request. In some embodiments, the TAS (128) may receive at least one triggered service from the at least one identified network function and forward the at least one triggered service towards the UE (104) via the communication interface.
[00100] In some embodiment, the interfacing unit (210) may be configured to establish at least one first thread and at least one second thread between the TAS (128) and the CAPIF (116). In an embodiment, the at least one first thread and at least one second thread are established using the HTTP interface, allowing for concurrent data transmission and enabling the TAS (128) to handle multiple requests simultaneously. The threading mechanism ensures faster processing times, better resource management, and the ability to handle high volumes of requests, improving the overall performance and scalability of the system. The at least one first thread and at least one second thread are essential for managing the service request received from the UE. For example, the first thread is designed to receive the service request from the CAPIF to the TAS. The second thread comes into play once the TAS (128) has processed the service request and triggered corresponding services (like a click-to-call or callback service). The at least one second thread is responsible for sending the triggered service from the TAS back to CAPIF, which then forwards the triggered service to the UE. The use of multi-threading ensures that different tasks (like receiving and sending requests) can occur concurrently, greatly enhancing the system’s efficiency and responsiveness. Additionally, the multi-threaded communication also ensures that network services can be triggered and responded to without delays, allowing for real-time service management.
[00101] FIG. 3 illustrates an exemplary system architecture (300) for managing the one or more service requests in the network (106), in accordance with an embodiment of the present disclosure.
[00102] As shown in FIG. 3, the system architecture (300) includes a user equipment UE (302) (analogous to UE (104)), and an IMS network (304). The system architecture (300) may include a number of components (modules) such as an operational support system (OSS)/ business support system (BSS) (318), an element management system (EMS) (316), a media resource function (MRF) (314), a caller ring back tones (CRBT) (312) service, a diameter routing agent (DRA) (310), an online charging system (OCS) (308), a mobile number portability (MNP) module (306), a provisioning server (324), and a telephony application server (TAS) (322).
[00103] The UE (302) is connected to the IMS network (304) via the Session Initiation Protocol (SIP) to manage and control multimedia communication sessions. The SIP enables voice and video communication over the internet. SIP handles the signaling and control of multimedia sessions. SIP uses a text-based message format that can be extended and customized to suit different needs and scenarios. The SIP message includes a request line or a status line, followed by a set of headers and an optional message body. The request line or status line indicates a method, a universal resource identifier (URI), and a version of the protocol. The set of headers provides additional information about the sender, the receiver, the session, and the message. The message body can contain session description protocol (SDP) or other data types. SDP defines the media formats, codecs, and parameters for each session.
[00104] For example, when a call is initiated by a user A (calling party) through a user equipment, a user equipment of a user B (receiving party) receives an INVITE message (not shown in FIG. 3). After receiving the invite message, the user equipment of the user B rings. In SIP, a response titled as "180 Ringing" is configured to notify the calling party that the call has been initiated and assure the calling party that the receiving party has received the INVITE message. Multiple SIP messages are exchanged between the user A and the user B during a signaling plane, and during a data plane. During the signaling plane, once all the messages are successfully transferred from the user A to the user B party, then a call is established between the user A to the user B. As these multiple SIP messages are being exchanged in the signaling plane, it is the responsibility of the (TAS) (322) to pass on successfully all the messages from the user A to the user B.
[00105] All the SIP messages are independent and when the invite message is received by the TAS (322), and the TAS (322) executes a service logic as per user management module (UMM) configured logic. The UMM is a tool used to manage user accounts, permissions, and access to services and resources within the network. The TAS (322) may send the INVITE message to the user B. Post the processing of the INVITE message, the TAS (322) receives other messages from other users intended to connect over the network. In an example, the TAS (322) receives a plurality of messages in parallel. In an aspect, the TAS (322) is a multi-threaded application.
[00106] The OSS (318) is configured to manage network operations and maintenance. The BSS is configured to handle billing, customer management, and revenue assurance. The OSS/BSS (318) is essential for telecom service providers to manage their operations, deliver services to customers, and generate revenue. In an aspect, the provisioning server (324) is connected to the OSS/BSS (318) via a load balancer (320). In an embodiment the load balancer (320) may be a F5 module. In an example, the load balancer (320) is connected to the OSS/BSS (318) via RESTful APIs (REST).
[00107] The EMS (316) includes various systems and applications for managing various network elements (NEs) on a network element-management layer (NEL). The EMS (316) is configured to manage one or more of a specific type of telecommunications network element. The EMS (316) manages the functions and capabilities within each NE but does not manage the traffic between different NEs in the network. The EMS (316) provides a foundation to implement OSS architectures that enable service providers to meet customer needs for rapid deployment of new services, as well as meeting stringent quality of service (QoS) requirements. The EMS (316) is connected to the TAS (322), provisioning server (324) and the OSS/BSS (318) via RESTful APIs (Rest).
[00108] The MRF (314) is configured to provide virtualization of networks to its network providers. The MRF (314) provides media services like announcements, tones, and conferencing for VoLTE, Wi-Fi calling, and fixed VoIP solutions. The MRF (314) is connected to the TAS (322) via the SIP and Media Server Markup Language (MSML) to facilitate the control and management of media resources during call sessions.
[00109] The CRBT (312) service is configured to replace a standard audio clip with a clip selected by the user. Thus, CRBT (312) is a customizable ringtone or music that a subscriber may subscribe to replace the default ring back tone when the subscriber is called. The CRBT (312) service can be supported by different mobile network infrastructures including the circuit-switched GSM networks and IP multimedia networks such as IMS. By utilizing the CRBT (312) service, telecom companies can improve customer satisfaction and loyalty. The CRBT (312) and the TAS (322) are connected via the SIP to manage and control the delivery of ring-back tones to callers during call setup.
[00110] The DRA (310) is a functional element in a 3G or 4G (such as LTE) network that provides real-time routing capabilities to ensure that messages are routed among the correct elements in a network. The DRA (310) and the Telephony Application Server (TAS) are connected via Diameter protocol to manage and route authentication, authorization, and accounting (AAA) messages for telephony services.
[00111] The OCS (308) is a centralized platform that allows a service provider to charge a user for services in real-time. The OCS (308) handles the subscriber's account balance, rating, charging transaction control and correlation. With the OCS (308), the telecom operator ensures that credit limits are enforced, and resources are authorized on a per transaction basis. The OCS (308) and the DRA (310) are connected via the Diameter protocol to facilitate the exchange of real-time charging information and manage accounting messages for telecommunications services.
[00112] The MNP module (306) is configured to allow users to switch their mobile phone number between different mobile network providers while retaining their existing number. The MNP module (306) module allows customers to change their provider without having to change their phone number, making it easier to switch to a better plan or service. The MNP module (306) and the TAS (322) are connected via the SIP to manage and route calls effectively, ensuring proper handling of calls to ported numbers within the network.
[00113] In an operative aspect, the provisioning server (324) is embedded with the TAS (322) to fulfill the objective of the present disclosure. In an example, the provisioning server (324) includes an interfacing unit (e.g., analogous to the interfacing unit (210)). In an operative aspect, the interfacing unit communicates through the network with the REST interface. The interfacing unit may provide a configurable HTTP interface (e.g., the multi-threaded interface) that may help the TAS (322) to receive at least one service request from the UE (302). In an operative aspect, the interfacing unit may establish at least one first thread and at least one second thread between the the TAS (322) and the CAPIF respectively to manage the at least one received service request. In an aspect, the at least one first thread is configured to receive the at least one service request from the CAPIF to the TAS (322). In an aspect, the at least one second thread is configured to transmit the at least one triggered service from the TAS (322) to the CAPIF.
[00114] In an aspect, the at least one service request received from the UE (302) may correspond to a HTTP REST request. In an aspect, the TAS (322) receives the at least one service request through the CAPIF. In an aspect, the interfacing unit establishes at least one first thread and at least one second thread between the TAS (322) and the CAPIF. In an aspect, the TAS (322) receives the at least one service request from the UE (302) through the at least one first thread. In an aspect, after receiving the at least one service request, the at least one network function associated with the TAS (322) triggers a plurality of services for the UE (302). In an aspect, the TAS (322) transmits the triggered services to the UE (302) through the at least one second thread.
[00115] By way of an example, consider a scenario where a user initiates a click-to-call request through the UE (302). The first thread is created to receive this request from the CAPIF to the TAS (322). While the TAS (322) processes the received request, a second thread is already prepared to handle the next stage, i.e., sending the triggered service (such as the call initiation response) back from the TAS (322) to the CAPIF. Once the service is triggered (i.e., the call is initiated or the callback request is confirmed), the second thread ensures that the response is sent back to the CAPIF, which forwards the response to the UE (302). In the scenario, if another request (e.g., an ad-hoc conference request) arrives from a different UE, the TAS (322) may simultaneously handle this request by opening new threads. The multi-threaded approach ensures that the TAS (322) can process both requests concurrently without making one request wait for the other to finish. This concurrent processing improves system responsiveness and ensures that real-time services like calls and callbacks are handled efficiently, even during high-traffic loads.
[00116] In an aspect, the plurality of services triggered for the UE (302) by the TAS (322) includes at least one of a click to call service, request a call back service, virtual mobile number service, ad-hoc conference service.
[00117] Thus, the system architecture (300), as disclosed by the present disclosure, may provide the customized (configurable) interface with the CAPIF. The system architecture (300) handles the HTTP REST service request from the UE (302) as per the customer requirements. The system architecture (300), as disclosed by the present disclosure, consumes the HTTP REST service request received from the CAPIF and triggers the various services at the network for the UE (302). The system architecture (300), as disclosed by the present disclosure, provides an efficient and multi-threaded interface between the CAPIF and the TAS (322).
[00118] The system architecture (300), as disclosed by the present disclosure, helps in improving the network performance since the customers of the network can send the HTTP REST (user input) request in any service format, and the TAS (322) triggers the multiple services for the customers with minimal changes in the network configuration. Further, the present disclosure provides an efficient multi-threaded interface in which separate threads are created by the interfacing unit to receive the HTTP REST service request from the UE (302) and to send the processed HTTP REST service request to the UE (302). Thus, the network capacity is optimized, and the network performance can be improved. Thus, the present disclosure provides different network services to the customers based on the service requests that are triggered through the HTTP REST API. Therefore, the present disclosure provides an easily configurable and easy to integrate rest interface framework.
[00119] FIG. 4 illustrates an exemplary flow diagram of a method (400) for managing the one or more service request in the network, in accordance with an embodiment of the present disclosure, in accordance with an embodiment of the present disclosure.
[00120] At step 402, the method (400) includes receiving, by a server, at least one service request from a User Equipment (UE) using a Common Application Programming Interface Framework (CAPIF) and over a communication interface. In an embodiment, the at least one service request corresponds to the HTTP-based REST request. In an embodiment, the server may correspond to the TAS (128). Additionally, the communication interface may correspond to a hypertext transfer protocol (HTTP) interface.
[00121] At step 404, the method (400) includes analyzing, by the server, the at least one received service request to identify at least one network function associated with the server. In an embodiment, the at least one network function may include one or more of a Media Resource Function (MRF), a Mobile Number Portability (MNP), and a Charging Function (CHF), an Adaptive Troubleshooting and Operations Management Platform (ATOM), and a Call Session Control Function (CFX).
[00122] At step 406, the method (400) includes transmitting, by the server, the at least one received service request towards the at least one network function to trigger at least one service. In an embodiment, the at least one service corresponding to the at least one received service request may include one of: a click-to-call service, a request for callback service, a virtual mobile number service, or an ad-hoc conference service.
[00123] In an embodiment, the method (400) further includes processing, by the at least one network function, the at least one received service request. triggering, by the at least one network function, the at least one service corresponding to the at least one received service request based on the processing.
[00124] In an embodiment, the method (400) further includes receiving, by the server, at least one triggered service from the at least one identified network function. The method (400) further includes forwarding, by the server, the at least one triggered service towards the UE using the CAPIF over the communication interface (e.g., the HTTP interface). In an embodiment, the communication interface is a two-way interface, i.e., the communication interface not only allows the UE to send the service request to the TAS but also enables the TAS to forward responses and information received from the network function back to the UE. For example, once the TAS triggers a service through the CAPIF and receives a response or service data from the relevant network function (e.g., click-to-call confirmation or callback status), the TAS can send this information directly to the UE using the same communication interface. This two-way capability ensures seamless interaction between the UE and the network services, allowing for both service initiation and real-time feedback through the same configurable HTTP interface.
[00125] In an embodiment, the method (400) further includes establishing at least one first thread and at least one second thread between the server and the CAPIF respectively to manage the at least one received service request. The at least one first thread is configured to receive the at least one service request from the CAPIF and forward to the server. Additionally, the at least one second thread is configured to transmit the at least one triggered service from the server to the CAPIF.
[00126] In an exemplary embodiment, the present disclosure relates to a user equipment (UE) communicatively coupled with a network. The coupling includes steps of receiving, by the network, a connection request from the 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 UE is configured to generate at least one service request. The at least one service request is managed in the network by a method that includes receiving, by a server, at least one service request from the UE using the CAPIF and over a communication interface. The method further includes analyzing, by the server, the at least one received service request to identify at least one network function associated with the server. The method further includes transmitting, by the server, the at least one received service request towards the at least one network function to trigger at least one service.
[00127] In an embodiment, the present disclosure facilitates the adaptation of the MSGin5G application enabler layer to the Common API Framework (CAPIF). In an embodiment, the MSGin5G service is a message enabler for applications. An application client (APP1 Client) in UE A utilizes MSGin5G Service to send a message to UE B. In this context, the system architecture enables seamless integration of multiple network functions and services. Specifically, the MSGin5G Server and the Application Server may support CAPIF to enable efficient communication between telecom applications and network resources.
[00128] When CAPIF is supported, the MSGin5G Server acts as an API provider and shall comply with the CAPIF API provider domain functions:
• CAPIF-2/2e
• CAPIF-3/3e
• CAPIF-4/4e
• CAPIF-5/5e
[00129] These functions enable the MSGin5G Server to expose its services and capabilities efficiently, while maintaining robust security and monitoring mechanisms. This ensures that the server can interact with multiple Application Servers and other network components in a secure and scalable manner.
[00130] Furthermore, the Application Server in this embodiment acts as an API invoker, responsible for invoking the exposed APIs from the MSGin5G Server. To achieve this, the Application Server shall support the following CAPIF API invoker functions:
• CAPIF-1/1
• CAPIF-2/2e
[00131] By supporting these CAPIF functions, the present disclosure optimizes API-based communication between the Application Server (also referred to as the TAS (128)) and various network functions, such as Call Session Control Function (CFX), Charging Function (CHF), and Media Resource Function (MRF), thus improving the overall service delivery and network resource management.
[00132] In another embodiment, the present disclosure ensures that all communication between the API invoker and the CAPIF core functions adheres to the stringent security requirements. These security requirements protect user privacy, message integrity, and confidentiality.
[00133] The following security measures for the CAPIF-1/1e reference points are implemented:
• Mutual authentication between the API invoker and the CAPIF core function is supported.
• The transport of messages over the CAPIF-1 and CAPIF-1e reference points is integrity protected.
• Messages transported over these reference points are protected from replay attacks.
• Confidentiality protection is applied to ensure that the transport of messages remains secure.
• Privacy of the 3GPP user over the CAPIF-1 and CAPIF-1e reference points is protected.
• The CAPIF core function authorizes the API invoker prior to accessing the AEF (API Exposure Function).
• Authorization by the CAPIF core function is required before the API invoker can access the discover service API.
• The CAPIF core function authenticates both onboarding and offboarding requests from the API invoker.
[00134] For CAPIF-2/2e reference points (between the API invoker and the API exposing function), the security requirements are as follows:
• Mutual authentication between the API invoker and the API exposing function is supported.
• The transport of messages over the CAPIF-2 and CAPIF-2e reference points is integrity protected.
• Protection against replay attacks is enforced for these reference points.
• Confidentiality protection is applied during message transport.
• Privacy of the 3GPP user is protected.
• The API exposing function determines whether the API invoker is authorized to access the service API.
[00135] For CAPIF-3, CAPIF-4, and CAPIF-5 reference points, the security requirements are as follows:
• The transport of messages over these reference points is integrity protected.
• Confidentiality protection is applied to all message transport over these reference points.
• Protection against replay attacks is ensured.
• The CAPIF core function authenticates service API publishers to publish and manage service API information.
• Authorization of service API publishers by the CAPIF core function is required before they can publish and manage service API information.
• The CAPIF core function can request an explicit grant before onboarding a new API invoker.
[00136] Thus, by complying with the security requirements, the present disclosure ensures secure, confidential, and tamper-resistant communication over the CAPIF. This protects user data and API interactions and provides a high level of trust between the API invokers, exposing functions, and the CAPIF core function.
[00137] FIG. 5 illustrates an exemplary computer system (500) in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 5, the computer system (500) may include an external storage device (510), a bus (520), a main memory (530), a read only memory (540), a mass storage device (550), a communication port (560), and a processor (570). A person skilled in the art will appreciate that the computer system (500) may include more than one processor (570) and communication ports (560). Processor (570) may include various modules associated with embodiments of the present disclosure.
[00138] In an embodiment, the communication port (560) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (560) may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (500) connects.
[00139] In an embodiment, the memory (530) may be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (540) may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input/Output System (BIOS) instructions for the processor (570).
[00140] In an embodiment, the mass storage (550) may be any current or future mass storage solution, which may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).
[00141] In an embodiment, the bus (520) communicatively couples the processor(s) (570) with the other memory, storage and communication blocks. The bus (520) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB) or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (570) to the computer system (500).
[00142] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus (520) to support direct operator interaction with the computer system (500). Other operator and administrative interfaces may be provided through network connections connected through the communication port (560). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system (500) limit the scope of the present disclosure.
[00143] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skills in the art.
[00144] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.
[00145] While considerable emphasis has been placed herein on 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 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 implemented merely as illustrative of the disclosure and not as a limitation.
[00146] The present disclosure provides technical advancement related to managing the one or more service requests in the network. This advancement addresses the limitations of existing solutions by introducing a flexible, multi-threaded interface between a Telephony Application Server (TAS) and the Common API Framework (CAPIF) for handling HTTP-based Representational State Transfer (REST) requests. The disclosure involves the creation of separate threads for receiving and sending service requests between the TAS and CAPIF, which offer significant improvements in network performance, efficiency, and scalability. By implementing configurable HTTP interfaces and multi-threaded processing, the disclosed invention enhances the management of telecommunication services like click-to-call and virtual mobile numbers, resulting in more reliable service delivery, reduced complexity, and improved network adaptability to dynamic service demands.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00147] The present disclosure provides a system and a method for managing one or more service requests by providing a customized, efficient and multi-threaded interface between a Common Application Programming Interface Framework (CAPIF) and a Telephony Application Server (TAS).
[00148] The present disclosure provides a configurable HTTP-based communication interface that supports the processing of various service requests, such as click-to-call, virtual mobile number services, and conference services, thereby offering enhanced service versatility.
[00149] The present disclosure improves network resource utilization and service delivery by separating the processing of service requests into dedicated threads (e.g., the at least one first third and the at least one second thread), ensuring efficient handling of incoming and outgoing requests between the TAS and the CAPIF.
[00150] The present disclosure provides a customized HTTP-based communication interface (e.g., the multi-threaded interface) with the CAPIF, designed to handle REST messages designed to meet specific customer requirements. This flexibility allows TAS to consume REST requests received from CAPIF effectively and subsequently trigger corresponding network services. Furthermore, the implementation of an efficient multi-threaded interface with CAPIF improves overall performance by enabling parallel processing of incoming and outgoing REST requests, optimizing response times and enhancing service delivery.
,CLAIMS:CLAIMS
We claim:
1. A method (400) for managing one or more service requests in a network (106), the method (400) comprising:
receiving (402), by a server, at least one service request from a User Equipment (UE) (104) using a Common Application Programming Interface Framework (CAPIF) (116) and over a communication interface;
analyzing (404), by the server, the at least one received service request to identify at least one network function associated with the server; and
transmitting (406), by the server, the at least one received service request towards the at least one network function to trigger at least one service.

2. The method (400) as claimed in claim 1, further comprising:
processing, by the at least one network function, the at least one received service request; and
triggering, by the at least one network function, the at least one service corresponding to the at least one received service request based on the processing.

3. The method (400) as claimed in claim 2, further comprising:
receiving, by the server, at least one triggered service from the at least one identified network function; and
forwarding, by the server, the at least one triggered service towards the UE (104) using the CAPIF (116) over the communication interface.

4. The method (400) as claimed in claim 1, wherein the at least one service request corresponds to a Hypertext Transfer Protocol (HTTP) based Representational State Transfer (REST) request.

5. The method (400) as claimed in claim 1, wherein the communication interface corresponds to a HTTP interface, and wherein the server corresponds to a Telephony Application Server (TAS) (128).

6. The method (400) as claimed in claim 1, wherein the at least one service corresponding to the at least one received service request comprises one of: a click-to-call service, a request for callback service, a virtual mobile number service, or an ad-hoc conference service.

7. The method (400) as claimed in claim 1, wherein the at least one network function comprises one or more of: a Media Resource Function (MRF), a Mobile Number Portability (MNP), and a Charging Function (CHF), an Adaptive Troubleshooting and Operations Management Platform (ATOM), and a Call Session Control Function (CFX).

8. The method (400) as claimed in claim 1, further comprising:
establishing at least one first thread and at least one second thread between the server and the CAPIF (116) respectively to manage the at least one received service request,
wherein the at least one first thread is configured to receive the at least one service request from the CAPIF (116) and forward to the server, and
wherein the at least one second thread is configured to transmit the at least one triggered service from the server to the CAPIF (116).

9. A system (108) for managing one or more service requests in a network (106), the system (108) comprising:
a memory (202); and
a processing unit (206) coupled with the memory to execute a set of instructions stored in the memory (202), the processing unit (206) is configured to:
receive at least one service request from a User Equipment (UE) (104) using a Common Application Programming Interface Framework (CAPIF) (116) and over a communication interface;
analyze the at least one received service request to identify at least one network function associated with a server; and
transmit the at least one received service request towards the at least one network function to trigger at least one service.

10. The system (108) as claimed in claim 9, wherein the processing unit (206) is further configured to:
process, by the at least one network function, the at least one received service request; and
trigger, by the at least one network function, the at least one service corresponding to the at least one received service request based on the processing.

11. The system (108) as claimed in claim 10, wherein the processing unit (206) is further configured to:
receive, by the server, at least one triggered service from the at least one identified network function; and
forward, by the server, the at least one triggered service towards the UE (104) using the CAPIF (116) over the communication interface.

12. The system (108) as claimed in claim 9, wherein the at least one service request corresponds to a Hypertext Transfer Protocol (HTTP) based Representational State Transfer (REST) request.

13. The system (108) as claimed in claim 9, wherein the communication interface corresponds to a HTTP interface, and wherein the server corresponds to a Telephony Application Server (TAS) (128).

14. The system (108) as claimed in claim 9, wherein the at least one service corresponding to the at least one received service request comprises one of: a click-to-call service, a request for callback service, a virtual mobile number service, or an ad-hoc conference service.

15. The system (108) as claimed in claim 9, wherein the at least one network function comprises one or more of: a Media Resource Function (MRF), a Mobile Number Portability (MNP), and a Charging Function (CHF), an Adaptive Troubleshooting and Operations Management Platform (ATOM), and a Call Session Control Function (CFX).

16. The system (108) as claimed in claim 9, wherein the processing unit (206) is further configured to:
establish at least one first thread and at least one second thread between the server and the CAPIF (116) respectively to manage the at least one received service request,
wherein the at least one first thread is configured to receive the at least one service request from the CAPIF (116) and forward to the server, and
wherein the at least one second thread is configured to transmit the at least one triggered service from the server to the CAPIF (116).

17. A User Equipment (UE) (104) communicatively coupled to a network (106), the coupling comprises steps of:
receiving, by the network (106), a connection request from the UE (104);
sending, by the network (106), an acknowledgment of the connection request to the UE (104); and
transmitting a plurality of signals in response to the connection request, wherein the UE (104) is configured to generate at least one service request and wherein the at least one service request is managed in the network (106) by a method (400) as claimed in claim 1.