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
METHOD AND SYSTEM FOR MANAGING CALL CHARGING IN A NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of wireless communication system, more particularly relates to a method and system for managing call charging in a network.
BACKGROUND OF THE INVENTION
[0002] The present disclosure pertains to the field of telephony systems and, more specifically, to the interaction between the Online Charging System (OCS) and the Business Telephony Application System (BTAS) through the Diameter Routing Agent (DRA). The Diameter interface plays a crucial role in the charging process within an IP Multimedia Subsystem (IMS) network, as it facilitates subscriber charging for various telephony services.
[0003] In a standard implementation, the BTAS receives service requests from subscribers, typically initiated through the Session Initiation Protocol (SIP) interface, and sends charging requests to the OCS via the Diameter interface. The OCS processes these requests and provides a response that determines the call's further execution. This represents the conventional charging mechanism used across networks.
[0004] However, there is a need for a customized charging support in the BTAS, considering its primary purpose as a business telephony application server catering to enterprise users. Different types of enterprise subscribers often require distinct charging schemes tailored to their specific needs. This customization adds value to the BTAS solution, enabling flexible and business-driven charging capabilities.
[0005] The customized charging support addresses several problems and offers unique features. Firstly, it allows for charging enterprise users in a manner that aligns with their individual requirements. Instead of a one-size-fits-all approach, this customization enables differentiated charging based on subscriber types within the enterprise network.
[0006] Secondly, the behavior of the call can be governed based on the responses received via the Diameter interface. The BTAS can utilize the information in the Diameter responses to determine call handling and apply specific call policies accordingly. This flexibility enhances the overall user experience and service management within the BTAS environment.
[0007] Furthermore, the BTAS can map SIP response codes based on the Diameter responses received over the Ro interface. This mapping enables seamless interoperability between the Diameter and SIP protocols, ensuring accurate and consistent handling of call-related events and signaling.
[0008] The state of the art in telephony systems primarily focuses on standardized charging mechanisms and limited customization options. The customization provided by the BTAS allows for fine-tuning the charging process and call behaviour, thus improving the service delivery and meeting specific business requirements.
[0009] There is a need for offering a customized call charging support, to address the limitations of a standard charging mechanism and thereby, provide a more adaptable and business-centric solution. The subsequent sections of this patent specification will further describe the features, implementations, and advantages of the customized charging support within the BTAS, along with relevant technical details and embodiment.
SUMMARY OF THE INVENTION
[0010] One or more embodiments of the present disclosure provide a method and system for managing call charging in a network.
[0011] In one aspect of the present invention, a method of managing a call charging in a network is disclosed. The method includes the step of receiving a call request from at least one User Equipment via an interface. The method further includes the step of retrieving information pertaining to at least one of a call service type and a call service request from the received call request. The method further includes the step of determining if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) for charging the received call request. The method further includes the step of transmitting the CCR trigger to the OCS on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA). The method further includes the step of determining a Credit Control Answer (CCA) utilizing the information retrieved from the received call request to indicate a charging status and a valuation of the call request, thereby managing call charging in the network.
[0012] In one embodiment, the method further includes the step of determining a call behavior applicable to the received call request, wherein the call behavior is customizable based on a response received from the OCS and the call service type. The method further includes the step of applying the determined call behavior to the received call request.
[0013] In another embodiment, the call behavior pertains to an activity which includes one of continuing the call, deny the call, deny call with announcement and continue call with announcement.
[0014] In yet another embodiment, the call service type is one of an originating call and a terminating call.
[0015] In yet another embodiment, the call service request is one of at least a toll-free number dialing, Internet Protocol (IP) centrex services, and service for trunk users.
[0016] In yet another embodiment, the call request is received utilizing a Session Initiation Protocol (SIP) and the CCR trigger is transmitted to the OCS via the DRA utilizing a diameter interface.
[0017] In yet another embodiment, subsequent to checking a set of predefined conditions, the CCR trigger is transmitted to the OCS based on a satisfaction of a set of predefined conditions, wherein the set of pre-defined conditions are dependent on parameters such as service type, Closed User Group, and SIP method, wherein charging is customized by a service provider based on at least one of business requirements and the call service type.
[0018] In yet another embodiment, in response to transmission of the CCR trigger, the method further comprising the step of receiving a diameter response from the OCS. The method further includes the step of mapping the diameter response to a SIP response as customized by a service provider. The method further includes the step of implementing the call behavior at the at least one UE based on the mapping.
[0019] In yet another embodiment, the mapping of the diameter response to the SIP response is dependent on the call service type.
[0020] In yet another embodiment, the set of predefined conditions include at least one of a first condition to check information retrieved from the call received in order to identify which BTAS service type needs to be accessed and to determine whether the CCR trigger is required to be transmitted for the identified BTAS service type based on the customization, a second condition to determine a call type of an ongoing call, whether it is at least one of, a Closed User Group (CUG) class, an INTER call type, an INTRA call type or an Outside call type and to determine whether a Ro trigger is configured for the identified BTAS service type and a third condition to check which type of SIP invite is received, which includes at least one of, an invite request and update request in the call request and to determine the Ro trigger corresponding to the SIP invite received is enabled or disabled based on the customization.
[0021] In another aspect of the present invention, a system for managing call charging in a network is disclosed. The system includes a transceiver configured to receive a call request from an at least one User Equipment via an interface. The system further includes an extraction unit configured to retrieve information pertaining to at least one of a call service type and a call service request from the received call request. The system further includes a determination unit configured to determine if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) for charging the received call request. The system further includes the transceiver configured to transmit the CCR trigger to the OCS on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA). The system further includes the determination unit configured to determine a Credit Control Answer (CCA) utilizing the information retrieved to indicate a charging status and a valuation of the call request, thereby managing call charging in the network.
[0022] In another aspect of the present invention, a User Equipment (UE) is disclosed. One or more primary processors communicatively coupled to one or more processors. The one or more primary processors coupled with a memory. The memory stores instructions which when executed by the one or more primary processors causes the UE to transmit a call request to the one or more processors via an interface. Further, the one or more processors are configured to perform the method for managing call charging in a network.
[0023] In yet another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor. The processor is configured to receive a call request from an at least one User Equipment via an interface. The processor is further configured to retrieve information pertaining to at least one of a call service type and a call service request from the received call request. The processor is further configured to determine if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) for charging the received call request. The processor is further configured to transmit the CCR trigger to the OCS on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA). The processor is further configured to determine a Credit Control Answer (CCA) utilizing the information retrieved to indicate a charging status and a valuation of the call request, thereby managing call charging in the network.
[0024] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. 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.
[0026] FIG. 1 is an exemplary block diagram of an environment for managing call charging in a network, according to one or more embodiments of the present invention;
[0027] FIG. 2 is an exemplary block diagram of the system for managing call charging in a network, according to one or more embodiments of the present invention;
[0028] FIG. 3 is an exemplary flow diagram of the system of FIG. 2, according to one or more embodiments of the present invention; and
[0029] FIG. 4 is a flow diagram of a method for managing call charging in a network, according to one or more embodiments of the present invention.
[0030] FIG. 5 is a signal flow diagram illustrating the system for managing call charging in a network, according to one or more embodiments of the present disclosure.
[0031] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0032] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0033] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0034] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0035] The present invention provides a flexible and a customizable call charging support system in a network. The system allows service providers to configure charging triggers, call behavior, and SIP responses based on diameter responses received from the Online Charging System (OCS) over the Ro interface. By leveraging system configurations, service providers have full control over the charging mechanism and call handling. The present invention eliminates the need for any backend changes or code level changes. The present invention offers advantages such as tailored charging for different service types, configurable call behavior based on diameter responses, and easy mapping of SIP responses to the diameter responses.
[0036] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 for managing call charging in a network 106, according to one or more embodiments of the present invention. The environment 100 includes, a User Equipment (UE) 102, a server 104, a network 106 and a system 108. The UE 102 aids a user to interact with the system 108 to transmit a call request in order to establish a call within a network 106.
[0037] For the purpose of description and explanation, the description will be explained with respect to one or more user equipment’s (UEs) 102, or to be more specific will be explained with respect to a first UE 102a, a second UE 102b, and a third UE 102c, and should nowhere be construed as limiting the scope of the present disclosure. Each of the at least one UE 102 namely the first UE 102a, the second UE 102b, and the third UE 102c is configured to connect to the server 104 via the network 106.
[0038] In an embodiment, each of the first UE 102a, the second UE 102b, and the third UE 102c is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and 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.
[0039] The network 106 includes, by way of example but not limitation, one or more of 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. The network 106 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0040] The network 106 may also 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 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, a VOIP or some combination thereof.
[0041] The environment 100 includes the server 104 accessible via the network 106. The server 115 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, a processor executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defence facility side, or any other facility that provides service.
[0042] The environment 100 further includes a system 108 communicably coupled to the server 104 and each of the first UE 102a, the second UE 102b, and the third UE 102c via the network 106. The system 108 is adapted to be embedded within the server 104 or is embedded as the individual entity. However, for the purpose of description, the system 108 is described as an integral part of the server 104, without deviating from the scope of the present disclosure. The system 108 is configured to manipulate message in the network 106.
[0043] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.
[0044] FIG. 2 is an exemplary block diagram of the system 108 for managing call charging in a network 106, according to one or more embodiments of the present invention.
[0045] As per the illustrated and preferred embodiment, the system 108 to manage call charging in the network 106 is a Business Telephony Application Server (BTAS). The BTAS provides a full-featured telephony and multimedia application system. The BTAS helps to rapidly develop and deliver services for enterprise and residential customers. The BTAS contains the service logic that provides the basic call-processing services, including digit analysis, routing, call setup, call waiting, call forwarding, conferencing, etc. The BTAS also provides the service logic for invoking the media servers to provide the appropriate call progress tones and announcements.
[0046] The system 108 is a central component that handles various telephony services. The system 108 operates based on industry-standard protocols and leverages configuration capabilities to customize a charging process and a call behavior. In order for the system 108 to manage call charging in the network 106, the system 108 includes one or more processors 202, a memory 204, a database 218 and a User Interface module 220. The one or more processors 202 includes a transceiver 206, an extraction unit 208, a determination unit 210, a mapping unit 212, and an implementation unit 214. The one or more processors 202, hereinafter referred to as the processor 202, may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. However, it is to be noted that the system 108 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204.
[0047] As per the illustrated embodiment, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204 as the memory 204 is communicably connected to the processor 202. The memory 204 is configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0048] In an embodiment, the transceiver 206 of the processor 202 is communicably connected to each of the at least first UE 102a, the second UE 102b, and the third UE 102c via the network 106. Initially, the UE 102 transmits a call request to the processor 202 via an interface. Further the processor 202 is configured to perform the method for managing call charging in a network 106. Accordingly, the transceiver 206 is configured to receive a call request from the UE 102 via an interface. In one embodiment, the interface includes at least one of, but not limited to, an Application Programming Interface (API). The transceiver 206 is further configured to transmit, the Charging Control Request (CCR) trigger to the OCS 312 (shown in FIG. 3) subsequent to determination of the CCR trigger is required to be transmitted to the OCS 312.
[0049] In an embodiment, the extraction unit 208 of the processor 202 is configured to retrieve information pertaining to at least one of a call service type and a call service request from the call request received from the UE 102. In an embodiment, the call service type is one of an originating call and a terminating call. In an embodiment, the call service request is one of at least a toll-free number dialing, Internet Protocol (IP) centrex services, and service for trunk users. The IP Centrex service is a cloud-based telephony service. Businesses use it for Voice over Internet Protocol (VoIP) based communication to avoid having all the necessary equipment on-site. The IP Centrex centralizes telecommunication services, allowing enterprises to manage multiple locations and services through a single network provider.
[0050] In an embodiment, the determination unit 210 of the processor 202 is configured to determine whether a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) 312 for charging the call request received from the UE 102. The determination unit 210 checks a set of pre-defined conditions, based on which the transceiver 206 transmits the Charging Control Request (CCR) trigger to the OCS 312. The determination unit 210 is further configured to determine a Diameter Credit Control Answer (CCA) response utilizing the information retrieved pertaining to at least one of a call service type and a call service request to indicate a charging status and a valuation of the call request. In an embodiment, the valuation of the call request is performed by the OCS 312. The valuation of the call request pertains to ascertaining the charges for the call initiated by user. In another embodiment, the valuation of the call request corresponds to monetary charges incurred to the user for one or more of, initiating the call, using the calling service, call duration, making the call. The determination unit 210 is further configured to determine a call behavior based on the Diameter CCA response received from the OCS 102. In an embodiment, the call behavior pertains to an activity which includes at least one of, continuing the call, denying the call, denying call with an announcement and continuing the call with an announcement. Based on the determination of the call behavior, the determination unit 210 applies the determined call behavior to the call request. In other words, the ongoing call will be continued or denied by the determination unit 210.
[0051] In an embodiment, in order to support Credit Control via the diameter protocol, there are two diameter messages, the CCR (Credit Control Request) and the CCA (Credit Control Answer) response. The diameter protocol is related to the mobile communication networks, such as 4G LTE networks. The diameter protocol provides authentication, authorization, and accounting (AAA) messaging services for network access and data mobility applications in 3G, IP Multimedia Systems (IMS), and LTE/4G networks. The CCR represents a Diameter Credit-Control-Request message, which is transmitted to the OCS 102 by the processors 202. The CCA represents the Diameter CCA response which is transmitted by the OCS 102 to the processor 202. In general, the corresponding Diameter Credit-Control application messages for a Debit /Reserve Unit Request operation is a Credit-Control-Request (CCR) and for a Debit /Reserve Unit Response operation is Credit-Control-Answer (CCA).
[0052] In an embodiment, the mapping unit 212 of the processor 202 is configured to map the diameter responses to Session Initiation Protocol (SIP) responses as customized by the service provider. The mapping of the diameter responses to the SIP responses is dependent on the call service type. The mapping unit 212 enables service providers to map SIP responses to specific diameter responses which ensures consistent and appropriate handling of call-related events. Service providers customize the SIP responses using a user interface module 220 according to their preferences and requirements. In one embodiment, the diameter responses are received by the system 108 from the OCS 312 and the SIP responses are stored in a database 218.
[0053] In one embodiment, the Session Initiation Protocol (SIP) is a signaling protocol that enables the Voice Over Internet Protocol (VoIP) by defining the messages sent between endpoints and managing the actual elements of a call. SIP is used for initiating, maintaining, modifying and terminating real-time communications sessions between Internet Protocol (IP) devices. SIP enables voice, messaging, video and other communications applications and services between two or more endpoints on IP networks. The SIP response provides information about the status of the call.
[0054] The database 218 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 212 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0055] In an embodiment, the user interface module 220 of the system 108 includes a variety of interfaces, for example, a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface module 220 allows service providers to configure and customize a charging mechanism, a call behavior, and Session Initiation Protocol (SIP) responses.
[0056] In an embodiment, the implementation unit 214 of the processor 202 is configured to implement the call behavior at the at least one UE 102 based on the mapping of the diameter responses with the SIP responses configured by the service providers. The call behavior pertains to an activity which includes one of continuing the call, denying the call, denying the call with an announcement and continuing the call with an announcement. For example, when the diameter response is received from the OCS 312, the implementation unit 214 of the system 108 decides whether to continue the ongoing call or deny the ongoing call based on the mapping of the diameter responses to the SIP responses.
[0057] The transceiver 206, the extraction unit 208, the determination unit 210, the mapping unit 212, and the implementation unit 214 in an exemplary embodiment, are implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 202. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 202 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 204 may store instructions that, when executed by the processing resource, implement the processor 202. In such examples, the system 108 may comprise the memory 204 storing the instructions and the processing resource to execute the instructions, or the memory 204 may be separate but accessible to the system 108 and the processing resource. In other examples, the processor 202 may be implemented by electronic circuitry.
[0058] FIG. 3 illustrates an exemplary block diagram of an architecture for the system 108 of FIG. 2, according to one or more embodiments of the present invention. More specifically, FIG. 3 illustrates the system 108 configured for managing call charging in a network 106. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the UE 102 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure. The FIG. 3 includes a UE 102, the system 108, a Diameter Routing Agent (DRA) 310 and an Online Charging System (OCS) 312.
[0059] The Diameter Routing Agent (DRA) 310 is a functional element in a 3G or 4G (such as LTE) network that provides real-time routing capabilities to ensure that request/messages/calls are routed among the correct network elements in the network. The Online charging system (OCS) 312 is a system allowing a communications service provider to charge their customers, in real time, based on service usage. The diameter interface connects the DRA 310 with the OCS 312 in a diameter protocol based mobile communication networks, such as 4G LTE networks. The diameter protocol provides authentication, authorization, and accounting (AAA) messaging services for network access and data mobility applications in 3G, IP Multimedia Systems (IMS), and LTE/4G networks.
[0060] For the purpose of description of the exemplary embodiment as illustrated in FIG. 3, the User Equipment (UE) 102 uses network protocol connection to communicate with the system 108. Accordingly, the UE 102 is configured to transmit a call request to the system 108 via an interface.
[0061] In an embodiment, the network protocol connection is the establishment and management of communication between the UE 102 and the system 108 over the network 106 using a specific protocol or set of protocols. The network protocol connection includes, but not limited to, Session Initiation Protocol (SIP), System Information Block (SIB) protocol, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Simple Network Management Protocol (SNMP), Internet Control Message Protocol (ICMP), Hypertext Transfer Protocol Secure (HTTPS) and Terminal Network (TELNET).
[0062] In an embodiment, the UE 102 includes a primary processor 302, a memory 304, and a user interface 306. In alternate embodiments, the UE 102 may include more than one primary processor 302 as per the requirement of the network 106. The primary processor 302, may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0063] In an embodiment, the primary processor 302 is configured to fetch and execute computer-readable instructions stored in the memory 304. The memory 304 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 304 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0064] In an embodiment, the user interface 306 of the UE 102 includes a variety of interfaces, for example, a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface module 306 is configured to allow a user to transmit a call request to the processor 202. The user interface module 306 facilitates communication with the system 108.
[0065] In an embodiment, Diameter Routing Agent (DRA) 310 provides a real-time routing capability to ensure that calls are routed among the correct elements in a network 106. The DRA 310 connects the system 108 with the OCS 312 via at least one of, a diameter interface and a Ro interface. Diameter is a protocol used for authentication, authorization, and accounting (AAA) in IP networks. Diameter interface enables communication between the system 108 and the DRA 310.
[0066] In an embodiment, the Ro interface is a 3rd Generation Partnership Project (3GPP) reference point that describes the connection to the OCS 312 from another functional component. The Ro interface supports Ro protocol which allows a Charging Trigger Function (CTF) to issue charging events to the OCS 312. The charging events can be immediate, event-based, or session-based. The Ro interface is the interface between the system and the OCS 312. The Ro trigger is configured to trigger the online charging via the Ro interface based on the identified call service type.
[0067] In an embodiment, the Online charging system (OCS) 312 performs charging calculations based on the information received retrieved pertaining to at least one of a call service type and a call service request and provides a Diameter Credit Control Answer (CCA) response indicating the charging status and valuation of the call. The system 108 connects to the OCS 312 through a DRA 310 over at least one of, the diameter interface and the Ro interface. Diameter interface and Ro interface enables communication between the system 108 and the OCS 312, ensuring secure and reliable exchange of charging-related information.
[0068] For example, when a user initiates a call, the system 108 receives the call signaling through the Session Initiation Protocol (SIP). SIP is a protocol used for establishing, modifying, and terminating multimedia sessions over IP networks. The system 108 processes the SIP requests/messages and determines the call service type and specific call service request. Further based on the call service type and subsequent to checking the set of pre-defined conditions, the system 108 determines whether a Charging Control Request (CCR) trigger is required to be transmitted to the OCS 312 for charging the call. This configuration is customizable by the service provider utilizing the user interface module 220, allowing service providers to define charging triggers according to their business requirements. For example, different charging triggers can be set for toll-free number calls, IP Centrex services, or specific user categories.
[0069] Once the decision is made to charge the call, the system 108 transmits the CCR trigger to the OCS 312 over the Diameter interface and the OCS 312 performs charging calculations based on the received information pertaining to at least one of a call service type and a call service request and provides a Diameter Credit Control Answer (CCA) response indicating the charging status and valuation of the call. Based on the diameter CCR response received from the OCS 312, the system 108 determines the call behavior. This call behavior is configurable by the service provider and can be tailored to specific diameter response codes. The system 108 includes rules which allows service providers to define actions such as call continuation, call denial, call denial with announcement, or call continuation with announcement. These actions are associated with different diameter response codes, ensuring flexible control over call handling. For example, let us consider that the system 108 receives a Diameter error response with code 5030. The service provider configures different actions based on the diameter error response with code 5030. If service provider configures system 108 utilizing the user interface module 220 to ignore the error, the system 108 will disregard the error and continue the call. Alternatively, if service provider configures system 108 to reject the call, the system 108 will terminate the call.
[0070] The system 108 includes rules which are configured at run time by the service providers. These rules facilitate service providers to control the charging process and the call behavior. For example, the service provider configures the system 108 to transmit the Charging Control Request (CCR) triggers for a particular service type such as society centrex calls. In other words, the system 108 will only charge for a particular service type requested by the user based on the configuration performed by the service provider utilizing the user interface module 220.
[0071] FIG. 4 is a flow diagram of a method 400 for managing call charging in a network 106, according to one or more embodiments of the present invention. For the purpose of description, the method is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0072] At step 402, the method 400 includes the step of receiving a call request from an at least one User Equipment 102 via an interface. In one embodiment, transceiver 206 of the processor 202 is configured to receive a call transmitted from the UE 102. The call request is received utilizing a Session Initiation Protocol (SIP).
[0073] At step 404, the method 400 includes the step of retrieving information pertaining to at least one of a call service type and a call service request from the received call request. In one embodiment, the extraction unit 208 of the processor 202 is configured to retrieve information from the received call request. The call service type is one of an originating call and a terminating call. The call service request is one of at least a toll-free number dialing, Internet Protocol (IP) centrex services, and service for trunk users.
[0074] At 406, the method 400 includes the step of determining if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) for charging the received call request. The determination unit 210 determines if CCR trigger is required to be transmitted to an OCS 312 subsequent to checking the set of predefined conditions which are dependent on parameters such as service type, Closed User Group, and SIP method.
[0075] The set of predefined conditions include a first condition to check information retrieved from the call received in order to identify which service types are required for the user and to determine whether the CCR trigger is required to be transmitted for the identified service type based on the customization done by the service provider. For example, if the user requires a specific type of service, the determination unit 210 identifies the required service type and checks whether the service provider had provided customization utilizing the user interface module 220 related to charging for that specific service type based on which the determination unit 210 determines if there is a need to transmit a CCR for the required service type .The set of predefined conditions further include a second condition in order to determine a call type of an ongoing call, whether it is at least one of, a Closed User Group (CUG) class, an INTER call type, an INTRA call type or an Outside call type and to determine whether a Ro trigger is configured for the identified service type. The set of predefined conditions further include a third condition to check which type of SIP invite is received at the system 108, which includes at least one of, an invite request and update request in the call request and to determine the Ro trigger corresponding to the SIP invite received is enabled or disabled based on the customization done by the service provider.
[0076] In one embodiment, the Closed User group (CUG) is a supplementary service provided by the service providers to mobile subscribers/users who can make and receive calls from any member associated within the group. The INTRA call is a type of an ongoing call which is considered as the local call while INTER call is a type of an ongoing call which is considered as the long-distance call.
[0077] At 408, the method 400 includes the step of transmitting the CCR trigger to the OCS on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA). Subsequent to checking the set of predefined conditions by the determination unit 210, the transceiver 206 transmits the CCR trigger to the OCS 312 via a Diameter Routing Agent (DRA) utilizing a diameter interface for charging the call.
[0078] At 410, the method 400 includes the step of determining a Credit Control Answer (CCA) utilizing the information retrieved from the received call request to indicate a charging status and a valuation of the call request, thereby managing call charging in the network. In one embodiment, the OCS 312 performs charging calculations based on the received information from the received call request and provides a Diameter Credit Control Answer (CCA) response indicating the charging status and valuation of the call. The system 108 evaluates the diameter responses received from the OCS 312 to make decisions regarding call continuation or denial. For example, the system 108 receives a diameter error response with code 5030. The service provider configures different actions utilizing the user interface module 220 based on the diameter error response. If service provider configures to ignore the error, the system 108 will disregard the error and continue the call. Alternatively, if service provider configures to reject the call, the system 108 will terminate the call and may play an announcement to the calling party such as UE 102.
[0079] The described method provides service providers with the ability to customize and configure the charging mechanism, call behavior, and SIP responses within the system 108. This customization offers tailored and flexible call charging support based on the call service types, the SIP methods, and the diameter responses. The system 108 ensures secure and reliable communication with the OCS 312, facilitating efficient charging control and call handling. The runtime control and flexibility empower service providers, eliminating the need for extensive backend development or coding.
[0080] FIG. 5 is a signal flow diagram illustrating the system for managing call charging in a network, according to one or more embodiments of the present disclosure.
[0081] At step 502, the user initiates a call request via the UE 102.
[0082] At step 504, the transceiver 206 of the processor 205 receives the call request initiated by the user and forwards the call request to the extraction unit 208.
[0083] At step 506, the extraction unit 208 retrieves information pertaining to at least one of a call service type and a call service request from the received call request and transmits a determination request to the determination unit 210.
[0084] At step 508, the determination unit 210, determines a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) 312 for charging the received call request and transmits a response to the transceiver 206.
[0085] At step 510, based on the response from the determination unit 210, the transceiver 206 transmits the CCR trigger to the OCS 312 via a Diameter Routing Agent (DRA) 310.
[0086] At step 512, the OCS 312 transmits a response to the determination unit 206. The response is a diameter response related to the call request. The response indicates a charging status and a valuation of the call request.
[0087] At step 514, the determination unit 210 receives the response from the OCS 312 and transmits a response to the transceiver 206 subsequent to determining a call behavior applicable to the received call request. The call behavior is customizable by a service provider based on a response received from the OCS 312 and the call service type. Further, the determination unit 210 applies the determined call behavior on the received call request.
[0088] At step 516, the transceiver 206 transmits the applied call behavior on the received call request which is related to call continuation of the call or the denial of the call.
[0089] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 202. The processor 202 is configured to receive a call request from an at least one User Equipment via an interface. The processor 202 is further configured to retrieve information pertaining to at least one of a call service type and a call service request from the received call request. The processor 202 is further configured to determine if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) 312 for charging the received call request. The processor 202 is further configured to transmit the CCR trigger to the OCS 312 on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA) 310. The processor 202 is further configured to determine a Credit Control Answer (CCA) utilizing the information retrieved to indicate a charging status and a valuation of the call request, thereby managing call charging in the network.
[0090] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-5) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0091] The present disclosure provides technical advancement. For example, the invention provides customized call charging support tailored to the specific business needs of enterprise users. Further, different types of subscribers can be charged differently, allowing service providers to offer flexible charging options based on service types and user categories. Further, this customization capability ensures that each enterprise user receives charging treatment appropriate for their requirements. Further, the invention enables service providers to govern call behavior based on diameter responses received from the Online Charging System (OCS). By configuring the system, service providers can define actions such as call continuation, call denial, call denial with announcement, or call continuation with announcement. This kind of flexibility empowers service providers to handle calls in a manner that aligns with their specific business policies and requirements. Further, service providers can map Session Initiation Protocol (SIP) error responses to specific diameter responses, ensuring consistent and appropriate handling of call-related events. This mapping capability of the invention allows service providers to customize SIP error responses according to their preferences and requirements. By mapping the appropriate SIP error response based on the Diameter response received, service providers can ensure seamless call handling and enhance the overall user experience. The invention eliminates the need for extensive backend development or coding. Further, the service providers can dynamically configure the system parameters and rules, providing runtime control and flexibility over the charging process, call behavior, and SIP responses. This streamlines the customization process and empowers service providers to adapt their charging mechanisms and call handling in real-time, without requiring significant system modifications. With the ability to charge different services in distinct ways, service providers can offer enhanced service differentiation to their enterprise users. By tailoring the charging process based on service types, service providers can provide unique pricing structures, packages, or features for each service category, further strengthening their value proposition and meeting the diverse needs of their customers.
[0092] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0093] Environment - 100;
[0094] User Equipment (UE) - 102;
[0095] Server - 104;
[0096] Network- 106;
[0097] System -108;
[0098] Processor - 202;
[0099] Memory - 204;
[00100] Transceiver – 206;
[00101] Extraction unit – 208;
[00102] Determination unit – 210;
[00103] Mapping unit – 212;
[00104] Implementation unit – 214;
[00105] Database – 218;
[00106] User Interface module – 220;
[00107] Primary processor- 302;
[00108] Memory- 304;
[00109] User Interface – 306;
[00110] DRA – 310;
[00111] OCS – 312.
,CLAIMS:CLAIMS
We Claim:
1. A method (400) of managing call charging in a network (106), the method (400) comprises the steps of:
receiving, by one or more processors (202), a call request from an at least one User Equipment (102) via an interface;
retrieving, by the one or more processors (202), information pertaining to at least one of a call service type and a call service request from the received call request;
determining, by the one or more processors (202), if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) (312) for charging the received call request;
transmitting, by the one or more processors (202), the CCR trigger to the OCS (312) on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA) (310); and
determining, by the one or more processors (202), a Credit Control Answer (CCA) utilizing the information retrieved from the received call request to indicate a charging status and a valuation of the call request, thereby managing call charging in the network (106).

2. The method (400) as claimed in claim 1, further comprising the steps of:
determining, by the one or more processors (202), a call behaviour applicable to the received call request, wherein the call behaviour is customizable based on a response received from the OCS (312) and the call service type; and
applying, by the one or more processors (202), the determined call behaviour to the received call request.

3. The method (400) as claimed in claim 2, wherein the call behaviour pertains to an activity which includes one of continuing the call, deny the call, deny call with announcement and continue call with announcement.

4. The method (400) as claimed in claim 1, wherein the call service type is one of an originating call and a terminating call.

5. The method (400) as claimed in claim 1, wherein the call service request is one of at least a toll-free number dialling, Internet Protocol (IP) centrex services, and service for trunk users.

6. The method (400) as claimed in claim 1, wherein the call request is received utilizing a Session Initiation Protocol (SIP) and the CCR trigger is transmitted to the OCS (312) via the DRA (310) utilizing a diameter interface.

7. The method (400) as claimed in claim 1, wherein subsequent to checking a set of predefined conditions, the CCR trigger is transmitted to the OCS (312), wherein the set of pre-defined conditions are dependent on parameters such as service type, Closed User Group, and SIP method, wherein charging is customized by a service provider based on at least one of business requirements and the call service type.

8. The method (400) as claimed in claim 1, wherein in response to transmission of the CCR trigger, the method (400) further comprising the steps of:
receiving, by the one or more processors (202), a diameter response from the OCS (312);
mapping, by the one or more processors (202), the diameter response to a SIP response as customized by a service provider;
implementing, by the one or more processors (202), the call behaviour at the at least one UE (102) based on the mapping.

9. The method (400) as claimed in claim 8, wherein the mapping of the diameter response to the SIP response is dependent on the call service type.

10. The method (400) as claimed in claim 7, wherein the set of predefined conditions include at least one of:
a first condition, to check information retrieved from the call received in order to identify which BTAS service type needs to be accessed and to determine whether the CCR trigger is required to be transmitted for the identified BTAS service type based on the customization;
a second condition, to determine a call type of an ongoing call, whether it is at least one of, a Closed User Group (CUG) class, an INTER call type, an INTRA call type or an Outside call type and to determine whether a Ro trigger is configured for the identified BTAS service type; and
a third condition, to check which type of SIP invite is received, which includes at least one of, an invite request and update request in the call request and to determine the Ro trigger corresponding to the SIP invite received is enabled or disabled based on the customization.

11. A User Equipment (UE) (102), comprising:
one or more primary processors (302) communicatively coupled to one or more processors (202), the one or more primary processors (302) coupled with a memory (304), wherein said memory (304) stores instructions which when executed by the one or more primary processors (302) causes the UE (102) to:
transmit a call request to the one or more processors (202) via an interface, wherein the one or more processors (202) are configured to perform the method (400) as claimed in claim 1.

12. A system (108) of managing call charging in a network (106), the system (108) comprising:
a transceiver (206) configured to receive, a call request from an at least one User Equipment (102) via an interface;
an extraction unit (208) configured to retrieve, information pertaining to at least one of a call service type and a call service request from the received call request;
a determination unit (210) configured to determine, if a Charging Control Request (CCR) trigger is required to be transmitted to an Online Charging System (OCS) (312) for charging the received call request;
the transceiver (206) configured to transmit, the CCR trigger to the OCS (312) on determination that the CCR trigger is required to be transmitted via a Diameter Routing Agent (DRA) (310); and
the determination unit (210) configured to determine, a Credit Control Answer (CCA) utilizing the information retrieved to indicate a charging status and a valuation of the call request, thereby managing call charging in the network (106).

13. The system (108) as claimed in claim 12, wherein the determination unit (210) is further configured to:
determine, a call behaviour applicable to the received call request, wherein the call behaviour is customizable based on a response received from the OCS (312) and the call service type; and
apply, the determined call behaviour on the received call request.

14. The system (108) as claimed in claim 13, wherein the call behaviour pertains to an activity which includes one of continue the call, deny the call, deny call with announcement and continue call with announcement.

15. The system (108) as claimed in claim 12, wherein the call service type is one of an originating call and a terminating call.

16. The system (108) as claimed in claim 12, wherein the call service request is one of at least a toll-free number dialling, Internet Protocol (IP) centrex services, and service for trunk users.

17. The system (108) as claimed in claim 12, wherein the call request is received utilizing a Session Initiation Protocol (SIP) and the CCR trigger is transmitted to the OCS (312) via the DRA (310) utilizing a diameter interface.

18. The system (108) as claimed in claim 12, wherein subsequent to checking a set of predefined conditions, the CCR trigger is transmitted to the OCS (312) ,wherein the set of pre-defined conditions are dependent on parameters including at least one of, service type, Closed User Group, and SIP method, wherein charging is customized by a service provider based on at least one of business requirements and the call service type.

19. The system (108) as claimed in claim 12, wherein in response to transmission of the CCR trigger:
the transceiver (206) is configured to, receive, a diameter response from the OCS (312);
a mapping unit (212) is configured to map, the diameter response to a SIP response as customized by a service provider;
an implementation unit (214) is configured to, implement, the call behaviour at the at least one UE (102) based on the mapping.

20. The system (108) as claimed in claim 19, wherein the mapping of the diameter response to the SIP response is dependent on the call service type.

21. The system (108) as claimed in claim 18, wherein the set of predefined conditions include at least one of:
a first condition, to check information retrieved from the call received in order to identify which BTAS service type needs to be accessed and to determine whether the CCR trigger is required to be transmitted for the identified BTAS service type based on the customization;
a second condition, to determine a call type of an ongoing call, whether it is at least one of, a Closed User Group (CUG) class, an INTER call type, an INTRA call type or an Outside call type and to determine whether a Ro trigger is configured for the identified BTAS service type; and
a third condition, to check which type of SIP invite is received, which includes at least one of, an invite request and update request in the call request and to determine the Ro trigger corresponding to the SIP invite received is enabled or disabled based on the customization.