FORM 2
THE PATENTS ACT, 1970 (39 of 1970) THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
COMMUNICATION NETWORK
APPLICANT
380006, Gujarat, India; Nationality : India
The following specification particularly describes
the invention and the manner in which
it is to be performed

RESERVATION OF RIGHTS
[0001] A portion of the disclosure of this patent document contains material,
which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, integrated circuit (IC) layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after 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 to a field of a communication network,
and specifically to a system and a method for provisioning and charging for enterprise plan in a communication 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 term “Attribute Value Pair (AVP)” used hereinafter in the
specification indicates a format used to represent information in various domains.
The Attribute Value Pair operates on a concept of key-value pairs. The attribute
serves as the key, while the value corresponds to the associated data. This structure
enables efficient storage, retrieval, and processing of information.
[0005] The term “Application Programming Interface (API) key” used
hereinafter in the specification indicates a unique identifier used to authenticate and
authorize access to a specific API (Application Programming Interface). APIs are
sets of rules, protocols, and tools that allow different software applications to
communicate with each other.
[0006] The term “enterprise plan” used hereinafter in the specification in
the specification indicates refers to a specialized service package designed

specifically for businesses or organizations or individual consumers. These plans are tailored to meet the unique requirements and demands of enterprises, which often have larger-scale operations, higher data usage, and more complex communication needs compared to individual users.
BACKGROUND
[0007] 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.
[0008] In a packet communication network, there are three parties involved:
service users (such as Session Initiation Protocol (SIP clients)), service providers (such as application servers), and an application broker that acts as a middleman (such as a SIP proxy). During a service link between a client (user equipment) and an application server, if the SIP proxy is not integrated and does not maintain state (that is, it is not a stateful SIP proxy), it cannot reliably provide a charging function for registered customers (users and service providers).
[0009] In a 5G system, the Session Management Function (SMF) handles
the task of session management. It works in conjunction with the Charging Function (CHF) to manage billing for subscriber accounts. During the management of a data connection, the SMF repeatedly communicates with the CHF to allocate data units for the connection and to keep track of the amount of data that has been used. CHF enables the account or subscription associated with the user equipment to be charged for the usage of the network resources. The CHF keeps track of the equipment’s usage, which makes it easier for both the user and the service provider to manage their respective responsibilities in a more efficient and cost-effective manner.
[0010] In general, CHF is deployed to a network side to complete the billing
function. The CHF includes Access Gateway Function (AGF), Cumulative

Distribution Function (CDF) and Charging gateway function (CGF). If the CHF is unavailable due to network issues or equipment malfunction, the SMF cannot reserve data units, leading to termination of the data connection and poor customer experience. To reduce hardware and operating costs in a large communication network, it is required for the CHF to work with multiple proxies simultaneously. However, it is a cumbersome task for the CHF to keep synchronization between multiple proxies of the communication network.
[0011] There is a need for a system that can provision and charge enterprise
plans in a communication network efficiently.
OBJECTS OF THE PRESENT DISCLOSURE
[0012] It is an object of the present disclosure to provide a charging system
for provisioning and charging enterprise plan in a communication network.
[0013] It is an object of the present disclosure to support the integration of
a charging function with a Business Telephony Application Server (BTAS) over a custom Ro (Diameter) interface.
[0014] It is an object of the present disclosure to support integration of a
charging function (CHF-L) with a provisioning system i.e., Fulfilment Management System (FMS) for provisioning of service (Application Programming Interface (API) key) wise counter threshold.
[0015] It is an object of the present disclosure to check number of calls per
API key (individual service per specific customer) and ensure that service usage is as per agreed service level agreements by comparing the number of calls with provisioned API key wise counter thresholds.
SUMMARY
[0016] The present disclosure discloses a system for provisioning and
charging for an enterprise plan in a communication network. The system includes a charging function that is configured to integrate with a business telephony application server (BTAS), and a provisioning system. The charging function includes a memory and one or more processors. The one or more processors are

configured to execute instructions comprising receiving a credit control request (CCR) request from the BTAS. The CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API) key. On responsive to the receiving the CCR request, the one or more processors are configured to fetch a current counter value corresponding to the received API Key from the provisioning system. The one or more processors are configured to compare the fetched current counter value with a provisioned value to determine availability of service based on the comparing results. Responsive to the determined availability of service, the one or more processors are configured to assign an available service corresponding to the CCR request and update the current counter value corresponding to the API Key.
[0017] In an embodiment, the charging function is configured to send a
successful response to the BTAS on assigning the available service corresponding to the received CCR request.
[0018] In an embodiment, the charging function is configured to send a fail
response back to BTAS, if the charging function fails to find the API Key, or the
current counter value corresponding to the service crosses the provisioned value, or
validity of user’s plan has expired, or the plan is not active.
[0019] In an embodiment, the charging function is configured to establish a
connection with a Session Data Layer (SDL) for storing and retrieving the data from
a plurality of network functions (NFs) across the communication network.
[0020] In an embodiment, the charging function is configured to
communicate with a Fault, Configuration, Accounting and Performance (FCAP) manager for performing Network Management System/Element Management System -related functions.
[0021] In an embodiment, the charging function includes a performance
management module, a configuration management module, a fulfilment management module, a session management module, a high availability module, a diameter stack management module, a provisioning module, an overload management module, a charging data record (CDR) management module, and a replication module.

[0022] In an embodiment, the charging function is configured to generate a
charging data record (CDR) for each received CCR request and store information
corresponding to each CCR request along with the API key.
[0023] In an embodiment, the charging function is configured to employ a
cluster having a plurality of charging nodes, wherein the plurality of charging nodes is configured to operate at least in one of an active mode, a standby mode, a spare mode.
[0024] In an embodiment, the charging function is connected with the
BTAS over Diameter Ro interfaces.
[0025] The present disclosure discloses a method for provisioning and
charging for an enterprise plan in a communication network. The method includes receiving, by a charging function, a credit control request (CCR) request from a business telephony application server (BTAS). The CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API) key. The method includes fetching, by the charging function, a current counter value corresponding to the received API Key from a provisioning system. The method includes comparing the fetched current counter value with a provisioned value to determine an availability of service based on the comparing results. Responsive to the determined availability of service, the method includes assigning, by the charging function, an available service corresponding to the CCR request. The method includes updating, by the charging function, the current counter value corresponding to the API Key.
[0026] In an embodiment, the method includes a step of sending a
successful response to the BTAS on assigning the available service corresponding to the received CCR request.
[0027] In an embodiment, the method includes a step of sending a fail
response back to BTAS, if the charging function fails to find the API Key, or the current counter value corresponding to the service crosses the provisioned value, or validity of user’s plan has expired, or the plan is not active.

[0028] In an embodiment, the method includes a step of establishing a
connection with a Session Data Layer (SDL) for storing and retrieving the data from
a plurality of network functions (NFs) across the communication network.
[0029] In an embodiment, the method includes a step of communicating
with a Fault, Configuration, Accounting and Performance (FCAP) manager to perform Network Management System/Element Management system-related functions.
[0030] In an embodiment, the method includes a step of generating a
charging data record (CDR) for each received CCR request and store information corresponding to each CCR request along with the API key.
BRIEF DESCRIPTION OF THE DRAWINGS
[0031] In the figures, similar components and/or features may have the
same reference label. Further, various components of the same type may be
distinguished by following the reference label with a second label that distinguishes
among the similar components. If only the first reference label is used in the
specification, the description is applicable to any one of the similar components
having the same first reference label irrespective of the second reference label.
[0032] The diagrams are for illustration only, which thus is not a limitation
of the present disclosure, and wherein:
[0033] FIG. 1 is an exemplary representation of a system for provisioning
and charging for an enterprise plan in a communication network, in accordance with
an embodiment of the present disclosure.
[0034] FIG. 2 illustrates an exemplary block diagram of a charging function,
in accordance with an embodiment of the present disclosure.
[0035] FIG. 3 is an exemplary representation of an internal cluster
architecture of a charging function, in accordance with an embodiment of the
present disclosure.
[0036] FIG. 4A illustrates an exemplary connection of the charging function
operating with a provisioning system, when a first node is in an active mode, in
accordance with an embodiment of the present disclosure.

[0037] FIG. 4B illustrates another exemplary connection of the charging
function operating with the provisioning system, when a second node is in an active
mode, in accordance with an embodiment of the present disclosure.
[0038] FIG. 4C illustrates another exemplary connection of the charging
function operating with the provisioning system, when a third node is in a spare
mode, in accordance with an embodiment of the present disclosure.
[0039] FIG. 5 is an exemplary representation of a configuration
management architecture of the system, in accordance with an embodiment of the
present disclosure.
[0040] FIG.6 is an exemplary representation of a software architecture of
the charging function, in accordance with an embodiment of the present disclosure.
[0041] FIG. 7 is an illustration of a non-limiting example of details of
computing hardware used in the system, in accordance with an embodiment of the
present disclosure.
[0042] FIG. 8 represents various steps of a method for provisioning and
charging for an enterprise plan in a communication network, in accordance with an
embodiment of the present disclosure.
LIST OF REFERENCE NUMERALS
100, 504 - System
102 - Business Telephony Application Server (BTAS)
104, 506 - Command Line Interface (CLI)
106 - Fulfilment Management System (FMS)
108, 308, 508 - Network Management System (NMS)
112, 212 - Charging Function
202 - One or more processor(s)
204 - Memory
206 - A Plurality of Interfaces
208 - Processing Engine
210 - Database
310 - Session Data Layer (SDL) Cluster

400, 420, 440 - Exemplary Connections
406 - Provisioning System
502 - Fault, Configuration, Accounting and Performance (FCAP) Manager
510 - Admin
710 - External Storage Device
720 - Bus
730 - Main Memory
740 - Read Only Memory
750 - Mass Storage Device
760 - Communication Port
770 - Processor
DETAILED DESCRIPTION
[0043] 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.
[0044] 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.
[0045] 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. [0046] 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.
[0047] 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.

[0048] 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 5 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. [0049] The terminology used herein is to describe particular embodiments only and
10 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
15 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
20 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
25 thereof may be used interchangeably without departing from the scope of the invention as defined herein.
[0050] 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
30 device is capable of receiving and/or transmitting one or parameters, performing function/s, communicating with other user devices, and transmitting data to the
11

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 5 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
10 the art for implementation of the features of the present disclosure.
[0051] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a
15 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
20 the present disclosure. More specifically, the processor is a hardware processor. [0052] 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
25 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.
[0053] While considerable emphasis has been placed herein on the
30 components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be
12

made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing 5 descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.
[0054] Session management in a 5G system is carried out by a network
function known as the Session Management Function (SMF). The SMF collaborates with another network function called the Charging Function (CHF) to
10 ensure that billing is accurately implemented to subscriber accounts. During the management of a data connection, the SMF is responsible for constantly checking with the CHF to reserve data units for the connection, as well as to report the amount of data the connection has consumed. The CHF then communicates with the carrier’s billing system to enter charges based on the amounts of data that have been
15 reported as consumed.
[0055] In general, the CHF is deployed at a network side to complete billing
function. The conventional CHF include Access Gateway Function (AGF),
Cumulative Distribution Function (CDF) and Charging gateway function (CGF).
[0056] The present disclosure provides a system and a method for
20 provisioning and charging an enterprise plan in a communication network. The present disclosure supports integration of a charging function (CHF-Lite (CHF-L)) with Business Telephony Application Server (BTAS) over custom Ro (Diameter) interface. The charging function offers high availability for Application Programming Interface (API) key provisioning. The present disclosure supports an
25 integration of the charging function with a northbound provisioning system. For example, the provisioning system is a fulfilment management system (FMS) for the provisioning of service (also known as Application Programming Interface (API) key) wise counter threshold. The present disclosure checks a number of calls per API key (individual service per specific customer) and ensures that service usage is
30 as per agreed service level agreements by comparing the number of calls with the provisioned API key wise counter thresholds.
13

[0057] The various embodiments of the present disclosure will be explained
in detail with reference to FIG. 1 to FIG.8.
[0058] FIG. 1 is an exemplary representation of a system (100) for
provisioning and charging for an enterprise plan in a communication network, in 5 accordance with an embodiment of the present disclosure. The system (100) includes a charging function (112), a business telephony application server (BTAS) (102), a command line interface (CLI) (104), a provisioning system (for example, a fulfilment management system (FMS)) (106), and a network management system (NMS) (108).
10 [0059] As shown in FIG. 1, the charging function (112) is connected to the
BTAS (102), CLI (104), FMS (106), and NMS (108). The charging function (112) is connected to the BTAS (102) over Diameter Ro interfaces. Further, the charging function (112) is connected to the provisioning system (106) over Hypertext Transfer Protocol (HTTP) interface. The charging function (112) is connected to
15 the NMS (108) over HTTP interface. In an example, the charging function (112) may be connected to a management and orchestration (MANO) over a REST interface.
[0060] The charging function (112) is responsible for handling the charging
or billing aspects of the telephony or IT service. The charging function (112) keeps
20 track of usage and generates bills or invoices accordingly.
[0061] The BTAS (102) is a server that hosts various telephony applications
(services) such as call routing, voicemail, conferencing, and other features tailored
for business communications.
[0062] The CLI (104) is a text-based interface for interacting with the
25 system by entering commands. The CLI (104) allows administrators or users to manage and configure various aspects of the system.
[0063] The FMS (106) is a system used to manage the fulfilment process,
which involves handling orders, provisioning services.
[0064] The NMS (108) is a system used to monitor and manage a
30 telecommunications network. The NMS (108) provides tools for monitoring
14

network performance, detecting faults or problems, and configuring network devices.
[0065] In an operative aspect, the charging function (112) is integrated with
the BTAS (102), and the provisioning system (106) (for example, FMS). The 5 charging function includes a memory and one or more processors. The one or more processors are configured to execute instructions. Under the instructions, the charging function (112) is configured to receive a credit control request (CCR) request from the BTAS (102). The CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API)
10 key. The API key is a unique identifier used to authenticate and control access to
an API. API keys are typically passed along with API requests either as URL
parameters, in HTTP headers, or as part of the request body, depending on the API’s
authentication mechanism.
[0066] In an aspect, the charging function is configured to listen for
15 incoming CCR requests (CCR messages) from the BTAS. The CCR messages are transmitted over a designated communication channel, such as Diameter or another protocol specified by the telecommunications network architecture. Upon receiving the CCR message, the charging function may be configured to parse the message to extract relevant information such as subscriber identification, requested service,
20 requested credit limit, and any other parameters included in the message. In an aspect, the charging function verifies the authenticity of the CCR message and checks whether the requesting entity (e.g., a subscriber or a service) is authorized to make the requested transaction. This may involve querying authentication and authorization databases or systems. Based on the information extracted from the
25 CCR message and the current state of the subscriber's account, the charging function makes a credit control decision. This decision determines whether the requested service should be granted, denied, or modified based on factors such as available credit balance, subscription plan, and network policies. Response Generation: After making the credit control decision, the charging function
30 generates a Credit Control Answer (CCA) message, which includes the result of the credit control decision (e.g., granted, denied, modified) along with any additional
15

information requested by the BTAS. The charging function sends the CCA message
back to the BTAS, informing it of the outcome of the credit control request. This
message includes the relevant information required by the BTAS to process the
transaction or take further action based on the credit control decision.
5 [0067] After receiving the CCR request from the BTAS, the one or more
processors (the charging function) are configured to fetch a current counter value corresponding to the received API key from the provisioning system. In an aspect, the provisioning system is configured to store a current counter value associated with each API. The provisioning system maintains the current counter value
10 corresponding to each API key for each service. For example, in the communication network, a number of services are available. For each service, a specific API key is specified.
[0068] The charging function (112) compares the fetched current counter
value with a provisioned value. This comparison helps determine the availability of
15 service based on the results. If the current counter value meets the provisioned value or falls within an acceptable range, the service is considered available. Responsive to the determined availability of service, the charging function is configured to assign an available service corresponding to the CCR request and update the current counter value corresponding to the API Key. For example, the fetched current
20 counter value corresponding to a specific API provisioned value is 50. The provisioned value for that specific API key is 55. As the fetched current counter value is less than the provisioned value, then the charging function assigns the service corresponding to the API Key and makes the current counter value 51. In an aspect, the current counter value may be reduced when a session corresponds to
25 the API key is completed/over.
[0069] The charging function (112) modifies the current counter value
based on the presence/absence of the service or the API Key in the received request. The charging function (112) is configured to receive a user request (for a specific service to be accessed) from a user and is configured to provide the requested
30 service to the user if the current counter value corresponding to the service is less than or equal to the provisioned value and a status of the user request is active. In
16

an embodiment, the charging function is configured to send a successful response to the BTAS on assigning the available service corresponding to the received CCR request.
[0070] In an embodiment, the charging function (112) is configured to send
5 a fail response back to BTAS, if the charging function fails to find the API Key, or the current counter value corresponding to the service crosses the provisioned value, or validity of user’s plan has expired, or the plan is not active. The charging function (112) is configured to reject the request if an API key associated with the service is not found or the current counter value corresponding to the service is
10 more than the provisioned value and a status of the user request is inactive.
[0071] In an aspect, the system is configured to integrate a network entity
(charging function CHF) with a peer node (BTAS) or provisioning system. The system is configured to provide session data across various sites (platform) to ensure geo-redundancy. The system is configured to establish a service-wise
15 counter threshold for provisioning the services. The system is configured to generate data based on the provisioned services along with a current value corresponding to each service. The system is configured to check provisioned records for specific services (API Keys) and adjust the service-wise counter based on the presence or absence of the service/API Key. API key is a unique identifier
20 used to authenticate and authorize access to an API.
[0072] The system is configured to validate a plurality of parameters of the
provisioned record using cache and SDL data. In an example, the plurality of parameters includes maximum hits allowed, plan type, plan validity, activation date and plan status.
25 [0073] The charging function is configured to establish a connection with a
Session Data Layer (SDL) for storing and retrieving the data from a plurality of
network functions (NFs) across the communication network.
[0074] The charging function (112) is configured to communicate with a
Fault, Configuration, Accounting and Performance (FCAP) manager for
30 performing Network Management System (NMS)/Element Management System (EMS) -related functions. NMS and EMS are vital components of network
17

infrastructure management. NMS oversees the entire network, offering fault detection, performance monitoring, configuration management, security enforcement, inventory tracking, topology mapping, and reporting. On the other hand, EMS focuses on individual network elements, managing their configuration, 5 monitoring their status, managing alarms, updating software/firmware, provisioning new devices, collecting performance statistics, and integrating with NMS for an interconnected management approach. In an embodiment, the charging function is configured to generate a charging data record (CDR) for each received CCR request and store information corresponding to each CCR request along with
10 the API key.
[0075] The charging function (112) is configured to connect with a dedicate
session data layer (SDL) for providing session data across the communication network. To establish a connection between the charging function and the SDL, various steps may be included based on the specific implementation and the
15 technologies involved. In an exemplary aspect, the steps may include:
a. Identification of SDL: The charging function needs to identify the
Session Data Layer it wants to connect to. This could involve
knowing the network address, such as an IP address or a domain
name, along with any authentication credentials required to access
20 the SDL.
b. Network Communication Protocol: Determine the network
communication protocol to be used for connecting to the SDL. The
choice of protocol depends on factors such as the nature of the data
being exchanged, security requirements, and compatibility with
25 existing systems.
c. Establishing Connection: Once the SDL is identified and the
communication protocol is chosen, the charging function initiates a
connection to the SDL server using the appropriate network
communication libraries or frameworks. This typically involves
30 opening a socket or making an HTTP request to an endpoint of the
SDL.
18

d. Authentication and Authorization: If the SDL requires
authentication and authorization, the charging function must provide
valid credentials during the connection establishment phase.
e. Data Exchange: Once the connection is established and
5 authenticated, the charging function can start exchanging data with
the SDL.
[0076] The SDL provides a data node functionality that is used to store the
session data in a persistent database. The SDL is divided into two sub-components:
1. SDL Master Node: responsible for managing the requests for cache from
10 the application.
2. SDL Slave Node: save the replicated copy of write requests and handle read
requests.
[0077] The charging function (112) generates a charging data record (CDR)
for each received CCR request, and to store a detailed information corresponding 15 to each CCR request along with the API key.
[0078] In an overall aspect, the charging function (112) (also known as
CHF-L) acts as an online charging function (OCS) for supporting the custom charging operation as per requirement of API as a service. The CHF-L supports following interactions.
20 1. CHF-BTAS Interaction: -The Ro reference point is defined for the
interactions between the CHF-Lite and the BTAS. When the CHF-Lite receives the CCR-I (CCR- initial) message from the BTAS, the charging function (112) checks the attribute-value pairs (AVPs) and compares them with the provisioned values to confirm if the service can be provided or not.
25 Further the charging function (112) maintains the periodic counter as
defined in specific API Key provisioning to ensure that service is only allowed for defined counter thresholds (provisioned value). In an example, the number of hits shall be calculated based on plan type being hourly or x_days i.e., if hourly, numbers will be calculated to absolute hour ending
30 time i.e., till 12:00 or till 13:00. Similarly in case of days, the day end shall
19

be assumed as 23:59:59. Validity is be calculated starting from Activation_Date.
2. CDR Generation: - The charging function (112) provides the feature to
generate the CDRs based on received CCR-I. CDR shall capture
5 cdrRecordNumber, cdrTimeStamp, apiKey, sessionId, ccRequestType,
chargingId, eventTimestamp, responseCode, Calling Party Address, Called
Party Address, Error Info. These records may be written in dot(.) current file
extension and once current file limit is reached with its configurable record
limit, application will close the file and convert it into dot(.) asn extension
10 file. The CDRs may be encoded using the ASN1 PER encoding algorithm.
CDR files shall have a predefined naming format and shall closed based on a number of records or time-based.
3. Provisioning Interface: - The charging function (112) provides the
provisioning APIs that shall be consumed by FMS for provisioning of API
15 key with required information in CHF-L. Other than API Key, the
provisioning record consists of Maximum Hits allowed, Plan type, Plan Validity, Activation Date and Plan Status. The record generated by the provisioning system like FMS may not be changed by the CHF-L. This includes status or validity or activation time, which will need to be managed
20 by northbound applications.
4. Overload Control: The CHF-L provides the overload control for a diameter
stack. The CHF-L allows users to define specific threshold limits to
effectively manage and regulate sudden surges of traffic within the network.
Moreover, the system also incorporates thresholds at the application level
25 to monitor and identify potential overload situations concerning CPU and
memory usage.
5. Tracing Module: - The charging function (112) provides the support for
tracing module. Trace logger functionality is provided for CCR/CCA call
flows for specified API Key. Additionally, users have access to
20

corresponding CLI commands, which can be utilized to enable the trace logger and perform CLI monitoring for the provided API Key in real time.
6. High Availability: - The charging function (112) serves as High Availability
Service (HSM) Managers. The HSM managers are deployed as a cluster
5 having Active-Standby-Spare architecture to provide the high available
cluster. High Availability State Manager (HSM) manages role assignment
for Active Service Manager. The HSM is responsible for handling fault
tolerance of the cluster. The HSM collocates with the CHF Lite (CL)
application container. The HSM dictates the Active/Standby/ Spare role to
10 be taken by CHF Lite (CL).
7. Health Check Module: - For ease of operations, the charging function (112)
supports automatic health check report generation using the health check
commands in CLI.
8. Performance Management: - The charging function (112) provides vast
15 array of counters for service operations supported by it. In addition to
service operation-based success and failure counters, additional counters for latency, NBI, Stack Counters, provisioning counters, TPS counters etc are provided by CHF Lite.
9. Fault Management: -FCAP Manager provides multiple alarms, which are
20 based on system function as well as threshold-based alarms. These alarms
are transferred to NMS system for notification.
10. Log Management: The charging function (112) provides the capability to
change the log level for various network functions (NF). For example,
different log levels at application-level vs. provisioning vs. HSM vs. Alarm
25 vs. CLI vs. replication vs. Tracing, etc.
11. Configuration Management: - The charging function (112) provides
configuration support via Command Line Interface (CLI).
21

[0079] FIG. 2 illustrates an exemplary block diagram (200) of the charging
function (212), in accordance with an embodiment of the present disclosure. In an aspect, the charging function (212) includes one or more processor(s) (202), a memory (204), a plurality of interfaces (206), a processing engine (208), and a 5 database (210). The one or more processor(s) (202) is configured to fetch and execute computer-readable instructions stored in the memory. The processor(s) (202) is configured to execute a sequence of instructions of the method for performing a number of operations in association with the PCF and the SPR, which may be embodied in a program or software. The instructions can be directed to the
10 processing unit, which may subsequently program or otherwise be configured to implement the methods of the present disclosure. In some examples, the processor(s) (202) is configured to control and/or communicate with large databases, perform high-volume transaction processing, and generate reports from large databases. The processor(s) (202) may be implemented as one or more
15 microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. The memory (204) is configured to store program instructions and data corresponding to a plurality of messages received from the PCF and the SCR. The program instructions include a
20 program that implements a method for enhancing a number of functionalities of the connected PCF and the SPR in accordance with embodiments of the present disclosure and may implement other embodiments described in this specification. The memory (204) may include any computer-readable medium known in the art including, for example, volatile memory, such as Static Random Access Memory
25 (SRAM) and Dynamic Random Access Memory (DRAM), and/or non-volatile memory, such as Read Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0080] The plurality of interfaces (206) includes a variety of interfaces, for
example, interfaces for data input and output devices, referred to as I/O devices,
30 storage devices, and the like. The plurality of interfaces (206) is configured to facilitate communication of the charging function (212). The plurality of interfaces
22

(206) also provides a communication pathway for one or more components of the charging function (212).
[0081] The processing engine (208) (processing unit) may be implemented
as a combination of hardware and programming (for example, programmable 5 instructions) to implement one or more functionalities of the processing engine (208). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the
10 hardware for the processing engine (208) 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 engine (208). In such examples, the charging function (212) may include the machine-readable
15 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 charging function (212) and the processing resource. In other examples, the processing engine(s) (208) may be implemented by an electronic circuitry.
20 [0082] In an embodiment, the processing engine (208) may support
integration of CHF-L (CHF-Lite) with BTAS over custom Ro (Diameter) interface. The processing engine (208) may support integration of CHF-L with a Northbound provisioning system, i.e., Fulfilment Management System (FMS) for provisioning of service (API key) wise counter threshold. The processing engine (208) may
25 check number of calls per API key (individual service per specific customer) and
ensure that service usage is as per agreed service level agreements by comparing
the number of calls with provisioned API key wise counter thresholds.
[0083] In an operative aspect, the BTAS is configured to initiate the CCR-I
towards CHF-Lite as per a service request. In an example, the BTAS includes the
30 service-specific-type AVP value as “7” to indicate the request is for API as a Service. Further, the BTAS includes the Service-specific-data with API Key value
23

against which CHF-Lite needs to do the check. CHF-Lite shall increment the counter which will be tracked for comparison with the plan type. If the running counter value is less than or equal to a maximum number of allowed hits while the status is still active and validity has not expired, CHF-Lite shall send the successful 5 response back to BTAS. On the alternate, if the API Key is not found or the running counter becomes more than the maximum number of allowed hits or validity has expired on the plan is not active, then a negative result-code value shall be sent across to BTAS. CHF-Lite also writes the CDRs as per the received and sent values for the fields.
10 [0084] For example, CHF-Lite may not maintain any session data. Thus,
CHF-Lite shall not validate Session-ID values for CCR-U (Credit Control Request - Update) / CCR-T (Credit Control Request - Termination). In the case of CCR-U, CCR-U may be suppressed from BTAS and thus may not be received at CHF Lite. In case CCR-U is sent by BTAS, CHF-Lite gives a default success response without
15 any validation. Further, CCR-T may be sent by BTAS only in special cases where call setup failed for service due to network/ BTAS issues. In that case, CCR-T is used to decrement the running counter for the specific API key. It must be noted here that CHF Lite is not configured to maintain the session state. This whether for received session-id in CCR-T, CCR-I was received earlier or not is not guaranteed.
20 CHF Lite may accept the CCR-T as another event for a specific API Key to decrement the running counter.
[0085] In an embodiment, the database (210) may comprise data that may
be either stored or generated as a result of functionalities implemented by any of the components of the processor(s) (202) or the processing engine(s) (208) or the
25 charging function (212).
[0086] Although FIG. 2 shows an exemplary block diagram (200) of the
charging function (212), in other embodiments, the charging function (212) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or
30 alternatively, one or more components of the charging function (212) may perform
24

functions described as being performed by one or more other components of the charging function (212).
[0087] FIG. 3 is an exemplary representation of an internal cluster (300)
architecture of the charging function, in accordance with an embodiment of the 5 present disclosure.
[0088] Referring to FIG. 3, the internal cluster architecture (300) of the
charging function (112) includes the NMS (308), the FMS (306), and dedicated SDL clusters (310) for providing session data across the communication network. As shown in FIG.3, the charging function (112) is configured to operate in at least 10 one mode i.e., an active mode, a hot standby mode, and a spare mode. In an example, the charging function (112) is connected to a plurality of high-availability state managers (HSMs) (HSM-1, HSM-2, and HSM-3).
[0089] The charging function (also referred as CHF-Lite (CL)) (112) is
deployed in Active/Standby/Spare architecture as mentioned below:
15 1. CHF-Lite (CL) Active is an application serving the requests in the local site.
2. CHF-Lite (CL) Hot Standby is a standby application which will become active when the currently running active instance goes down.
3. CHF-Lite (CL) Spare is the application running on the geographical redundant site which will become active when both the applications running
20 in local site goes down.
[0090] The CHF-Lite (CL) is configured to:
1. Handle the Diameter signalling traffic to/ from BTAS.
2. Provide Integration with FCAP Manager for NMS/EMS related functions.
3. Provide Connectivity with Session Data Layer (SDL) for storing and 25 retrieving the NF specific data.
[0091] The charging function (112) has an interconnectivity with the FMS
for provisioning of API key. The FCAP manager is configured for Fault, Configuration, Accounting and Performance (FCAP) management services. The
25

FCAP manager is also responsible for interacting with the NMS. The session data layer (SDL) (310) is used to store the session data in a persistent database.
[0092] The plurality of high availability state managers (HSMs) (HSM-1,
HSM-2, and HSM-3) is responsible for handling fault tolerance of the cluster. The 5 HSM collocates with the CHF Lite (CL) application container. The HSM dictates the Active/Standby/ Spare role to be taken by the CHF Lite (CL) application. The system provides a separate command line interface (CLI) for managing the application and the SDL (310). The CLI or Man-Machine Language (MML) is responsible for managing the application. The SDL-CLI is responsible for fetching 10 Session Data Layer statistics.
[0093] Referring to FIGS. 4A- 4C, the charging function (CHF Lite) offers
high availability for API key provisioning. The charging function may be deployed as the cluster which has a plurality of nodes. The plurality of nodes is configured to operate at least one in an active mode, in a standby mode, in a spare mode or a
15 combination thereof. As a part of the architecture, in the active mode/standby mode /spare mode, the CHF-Lite within the cluster is configured to carry traffic. In order to reduce the traffic, the present disclosure configures all three nodes at the end of the provisioning system (406). The provisioning system (406) sends the data to any of 3 nodes, and the charging function (CHF Lite) performs an internal
20 synchronization within the cluster. In case of request timeout or internal server error, the provisioning system (406) is configured to retry to transmit the request after some delta time.
[0094] FIG. 4A illustrates an exemplary connection (400) of a charging
function (not shown in FIG.) operating with the provisioning system (406), when a 25 first node (SM1) is in an active mode, in accordance with an embodiment of the present disclosure. In the described architecture, the plurality of nodes can operate in different modes: active mode, standby mode, spare mode, or a combination thereof. These modes determine the roles and responsibilities of each node within the cluster. Specifically, when operating in the active mode, the first node (SM1)
26

actively participates in processing and handling network traffic. A second node (SM2) is in a standby mode, and a third node (SM3) is in the spare mode. In the standby mode, a node remains ready to take over the active role in case of failure or when needed to balance the workload. The spare mode designates a node as a 5 backup or reserve, typically remaining idle until called upon to replace a failed active node.
[0095] FIG. 4B illustrates another exemplary connection (420) of the
charging function (112) operating with the provisioning system (406), when the second node (SM2) is in an active mode, in accordance with an embodiment of the 10 present disclosure. The first node (SM1) is in a spare mode, and a third node (SM3) is in the standby mode.
[0096] FIG. 4C illustrates another exemplary connection (440) of the
charging function (112) operating with the provisioning system (406), when the third node (SM3) is in a spare- active mode, in accordance with an embodiment of 15 the present disclosure.
[0097] As part of this architecture, the cluster is configured to carry traffic
when the cluster operates in any of these modes (active, standby, or spare). The CHF-Lite plays a crucial role in maintaining communication and coordination among nodes within the cluster. It facilitates the exchange of signals and 20 synchronization information, ensuring smooth operation and failover capabilities in the event of node failures or network disruptions.
[0098] In an operative aspect, the charging function is configured to receive
the API key corresponding to the service. In an example, the API key has standardized attributes and characteristics.
25 [0099] In an aspect, the API request may be changed by using three types
of modification requests given as:
a. Renewal modification request
b. Attribute modification request
27

c. Plan change modification request
[00100] In an aspect, ApiKey, modificationType and modifiedParamList
may be mandatory fields in all modification requests.
[00101] Renewal modification request: This request is used to renew an
5 existing plan. ApiKey, planValidity, modifiedParamList and modificationType may be mandatory fields in the renewal modification request. The charging function (112) checks whether the plan validity has expired and based on the result, executes the below operations.
[00102] Validity not expired: In this case, MP(Marketplace) /SE
10 (Subscription Engine) sends the API Key, recharge indication (modificationType) and validity via provisioning system. In an aspect, the subscription engine refers to a system or platform that enables businesses to offer subscription-based services or products within a marketplace environment. The marketplace refers to factors and forces that affect a firm's ability to build and maintain successful customer 15 relationships. Validity duration may be defined in days and may reflect the duration for which existing validity needs to be extended. The charging function (112) checks the previously configured validity days at CHF Lite and may add the newly provided validity duration to calculate the overall validity days. Activation-Date may remain same as was present before receiving the request.
20 [00103] Validity expired: In this case also, MP/SE sends the API Key,
recharge indication (modificationType) and validity via the provisioning system. In this case, as existing validity has already expired thus the charging function (112) needs to generate the activation DateTime as well. The charging function (112) creates the Activation DateTime as same system time at which recharge request is
25 received at CHF Lite from MP/SE via provisioning system. The charging function (CHF Lite) is configured to use the date received in the request as the validity date.
[00104] Attribute Modification request: Attribute modification request
updates one or more attribute’s values for existing API key. Apikey,
28

modificationType and modifiedParamList are mandatory fields in this modification
request. The following fields are conditional mandatory fields depending on
modified parameter list’s value.
1. maximumAllowedHits
5 2. planType
3. planValidity
4. activationDate
5. planStatus
[00105] Plan change modification request: Plan change modification request
10 may be used for only plan change. It updates all attribute’s values for existing API key. Following all below fields are mandatory.
1. apiKey
2. maximumAllowedHits
3. planType 15 4. planValidity

5. activationDate
6. planStatus
7. modificationType
8. modifiedParamList
20 [00106] The charging function (CHF Lite) checks if the plan validity is
expired or not and based on result below operations are executed:
1. Validity not expired: In this case, MP/SE sends API key, recharge indication
(modificationType) and all parameters associated with the new plan along
with activation DateTime is received by the CHF lite. CHF Lite checks if
25 the validity is expired or not. As the validity is not expired but the request
is for a plan change, CHF Lite ignores the activation date received from MP/SE via FMS and creates the activation datetime as the same system time at which the request is received. The rest of the parameters may be updated as per parameter values received in the request, including the validity. In
29

this case, the maximum hits/quota bucket is updated based on the time at
which the request has been received.
2. Validity expired: In this case, MP/SE sends API Key, Recharge Indication
(modificationType) and all parameters associated with new along with
5 Activation DateTime. CHF Lite checks whether validity has expired. As the
validity has expired but the request is for a plan change, CHF Lite overwrites all the provisioned parameters, including Activation DateTime and Validity, as per the parameter values received in the request.
[00107] FIG. 5 is an exemplary representation of a configuration
10 management architecture (500) of the charging function (112), in accordance with an embodiment of the present disclosure. As shown in FIG. 5, an admin (510) is configured to interact with the NMS (508), the FCAP manager (502), a number of command-line interfaces (CLIs) (506), and a number of service managers (504). The configuration management architecture (500) of the charging function (112) 15 provides the following ways for configuration:
1. Admin (510) is configured to connect with the NMS (508) from which the
CHF-L cluster is to be configured. The NMS component internally talks to
the FCAP Manager component on REST over an HTTP interface. FCAP
Manager supervises the configuration of the CHF Lite application of the
20 CHF-L cluster using an interface.
2. Admin (510) is configured to connect to the CLI for configuration
management of the CHF Lite Application. The CLI internally connects to
the CHF Lite using the REST interface.
[00108] FIG. 6 is an exemplary representation of a software architecture
25 (600) of the charging function (112), in accordance with an embodiment of the present disclosure.
[00109] As shown in FIG. 6, the charging function (112) includes a
performance management module (602), a high availability module (604), an overload management (606), a diameter stack management module (608), a
30

charging data record (CDR) management module (610), a fault management module (612), a configuration management module (614), a session management module (616), a provisioning module (620), and a replication module (618). The charging function (112) is configured to communicate with the operating operation 5 (622), and a network controller (624).
[00110] The performance management module (602) interacts with internal
services of the charging function (112) to fetch the performance counters and also integrates with a performance management system via the NMS to transfer key performance indicators data specific to the CHF-L cluster.
10 [00111] The high availability module (604) maintains high availability or
redundancy within the CHF-L cluster managed by the HSM. The diameter stack management module (608) creates Diameter connections with the peer node, BTAS.
[00112] The overload management module (606) is responsible for providing
15 the overload control function for the signalling interface. The overload management module (606) is also responsible for overload detection at the application layer by monitoring CPU and memory resources.
[00113] The CDR Management module (610) is responsible for writing
CDRs on receiving the CCR-I requests from the BTAS. The CDR Management 20 module (610) maintains a sequence number of CDR files.
[00114] The fault management module (612) integrates with the network
management system to provide fault information for the specific CHF-L cluster. In addition to integration with EMS, another module known as the Alarm Module also works with the Fault Management module. The alarm module is responsible for 25 generating success/ failure alarms and conditional alarms and provides the same to the FCAP manager for integration with the NMS.
31

[00115] The configuration management module (614) is part of various
micro services within the CHF-L cluster. It integrates with the NMS system, which helps push configuration changes into the CHF-L cluster. The configuration management module (614) also provides user interaction via CLI interfaces.
5 [00116] The session management module (616) integrates with the SDL
layer for Create, Read, Update and Delete Operations of the data related to CHF-L cluster as well as provisioning data received. In an aspect, the CHF-Lite supports various kinds of databases.
[00117] The replication module (618) is responsible for replication of cache
10 data from the active CHF-Lite to the standby CHF-Lite and the spare CHF-Lite. Further, the replication module (618) also manages auto bulk replication in case of restart. Manual replication using CLI is also possible using the replication module (618).
[00118] The provisioning module (620) provides the APIs that may be
15 consumed by FMS for the provisioning of API Keys and related information in the CHF-L cluster.
[00119] FIG. 7 is an illustration (700) of a non-limiting example of details of
computing hardware used in the system, in accordance with an embodiment of the present disclosure. As shown in FIG. 7, the system (100) may include an external 20 storage device (710), a bus (720), a main memory (730), a read only memory (740), a mass storage device (750), a communication port (760), and a processor (770). A person skilled in the art will appreciate that the system (100) may include more than one processor (770) and communication ports (760). Processor (770) may include various modules associated with embodiments of the present disclosure.
25 [00120] In an embodiment, the communication port (760) 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 (760) may be chosen
32

depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system (700) connects.
[00121] In an embodiment, the memory (730) may be Random Access
Memory (RAM), or any other dynamic storage device commonly known in the art. 5 Read-only memory (740) 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 (770).
[00122] In an embodiment, the mass storage (750) may be any current or
10 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 15 or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g., an array of disks (e.g., SATA arrays).
[00123] In an embodiment, the bus (720) communicatively couples the
processor(s) (770) with the other memory, storage, and communication blocks. The bus (720) may be, e.g., a Peripheral Component Interconnect (PCI)/PCI Extended 20 (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 (770) to the computer system (700).
[00124] Optionally, operator and administrative interfaces, e.g., a display,
25 keyboard, joystick, and a cursor control device, may also be coupled to the bus (720) to support direct operator interaction with the computer system (700). Other operator and administrative interfaces may be provided through network connections connected through the communication port (760). Components described above are meant only to exemplify various possibilities. In no way should
33

the aforementioned exemplary computer system (700) limit the scope of the present disclosure.
[00125] FIG. 8 represents various steps of a for provisioning and charging
for an enterprise plan in a communication network, in accordance with an 5 embodiment of the present disclosure.
[00126] At step (802), a charging function (112) receives a credit control
request (CCR) request from a business telephony application server (BTAS) (102). The CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API) key.
10 [00127] At step (804), the charging function (112) fetches a current counter
value corresponding to the received API Key from the provisioning system (106) and compares the fetched current counter value with a provisioned value to determine the availability of service based on the comparing results.
[00128] At step (806), the charging function (112), responsive to the
15 determined availability of service, assigns an available service corresponding to the CCR request. In an aspect, the charging function (112) sends a successful response to the BTAS on assigning the available service corresponding to the received CCR request.
[00129] The charging function (112) sends a fail response back to BTAS, if
20 the charging function fails to find the API Key, or the current counter value corresponding to the service crosses the provisioned value, or validity of user’s plan has expired, or the plan is not active.
[00130] At step (808), the charging function (112) updates the current
counter value corresponding to the API Key.
25 [00131] In an aspect, the method further includes a step of establishing a
connection with a Session Data Layer (SDL) for storing and retrieving the data from a plurality of network functions (NFs) across the communication network.
34

[00132] In an aspect, the method further includes a step of communicating
with a Fault, Configuration, Accounting and Performance (FCAP) manager for performing Network Management System/Element Management System-related functions.
5 [00133] In an aspect, the method further includes a step of generating the
charging data record (CDR) for each received CCR request and store information corresponding to each CCR request along with the API key.
[00134] The present disclosure is configured to provide an enhancement to
the online charging function (OCS) (charging function) such that the enhanced
10 charging function is able to check the number of calls per API Key (Individual Service per specific customer) and ensures that service usage is as per agreed service level agreements by comparing the number of calls with provisioned API key wise counter thresholds. The enhanced charging function is configured to provide more accurate charging plans and billable amounts, thereby increasing the
15 customer satisfaction. In a billing system, various scenarios may arise that require handling by charging function. These scenarios include situations where the charging function is unavailable due to network issues or equipment malfunction, the SMF cannot reserve data units, leading to termination of the data connection and poor customer experience. The current charging function employed with BTAS
20 can effectively handle these situations. The present disclosure is applicable to a wide range of applications that require real-time operation, including generating bills, generating plans, checking validity of plans associated with a user, and generating subscription plans for operational ease. The present disclosure is configured to be employed in a communication system related to charge customers,
25 in real time, based on service usage provided by the service provider.
[00135] 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
35

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 5 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.
[00136] While the foregoing describes various embodiments of the present
10 disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope thereof. The scope of the present disclosure is determined by the claims that follow. The present disclosure 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 present disclosure when 15 combined with information and knowledge available to the person having ordinary skill in the art.
ADVANTAGES OF THE PRESENT DISCLOSURE
[00137] The present disclosure provides a system for provisioning and
charging enterprise plan in a communication network.
20 [00138] The present disclosure supports integration of Charging Function-
Lite (CHF-L) with Business Telephony Application Server (BTAS) over custom Ro (Diameter) interface.
[00139] The present disclosure supports integration of CHF-L with a
provisioning system i.e., Fulfilment Management System (FMS) for provisioning
25 of service (Application Programming Interface (API) key) wise counter threshold.
[00140] The present disclosure checks number of calls per API key
(individual service per specific customer) and ensures that service usage is as per
36

agreed service level agreements by comparing the number of calls with provisioned API key wise counter thresholds.
37

Claims We claim:
1. A system (100) for provisioning and charging for an enterprise plan in a communication network, the system (100) comprising:
a charging function (112) configured to integrate with a business telephony application server (BTAS) (102), and a provisioning system (106), the charging function (112, 212) comprising: a memory (204); and
one or more processors (202) configured to execute instructions comprising:
receiving a credit control request (CCR) request from the BTAS (102), wherein the CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API) key;
responsive to the receiving the CCR request, fetching a current counter value corresponding to the received API Key from the provisioning system (106), and comparing the fetched current counter value with a provisioned value to determine an availability of service based on the comparison;
responsive to the determined availability of service, assigning an available service corresponding to the CCR request, and updating the current counter value corresponding to the API Key.
2. The system (100) as claimed in claim 1, the charging function (112) is configured to send a successful response to the BTAS (102) on assigning the available service corresponding to the received CCR request.
3. The system (100) as claimed in claim 1, the charging function (112) is configured to send a fail response back to the BTAS (102), if the charging function fails to find the API Key, or the current counter value

corresponding to the service crosses the provisioned value, or validity of user’s plan has expired, or the plan is not active.
4. The system (100) as claimed in claim 1, the charging function (112) is configured to establish a connection with a Session Data Layer (SDL) for storing and retrieving data from a plurality of network functions (NFs) across the communication network.
5. The system (100), as claimed in claim 1, the charging function (112), is configured to communicate with a Fault, Configuration, Accounting and Performance (FCAP) manager (502) to perform network management system/element management system-related functions.
6. The system (100) as claimed in claim 1, wherein the charging function (112) includes a performance management module, a configuration management module, a fault management module, a session management module, a high availability module, a diameter stack management module, a provisioning module, an overload management module, a charging data record (CDR) management module, and a replication module.
7. The system (100) as claimed in claim 1, wherein the charging function (112) is configured to generate a charging data record (CDR) for each received CCR request and store information corresponding to each CCR request along with the API key.
8. The system (100) as claimed in claim 1, wherein the charging function (112) is configured to employ a cluster having a plurality of charging nodes, wherein the plurality of charging nodes is configured to operate at least in one of an active mode, a standby mode, a spare mode.

9. The system (100) as claimed in claim 1, wherein the charging function (112) is connected with the BTAS (102) over Diameter Ro interfaces.
10. A method (800) for provisioning and charging for an enterprise plan in a communication network, the method (800) comprising:
receiving (802), by a charging function (112), a credit control request (CCR) request from a business telephony application server (BTAS) (102), wherein the CCR request includes a service-specific-type attribute-value-pair (AVP) value and an Application Programming Interface (API) key;
fetching (804), by the charging function (112), a current counter value corresponding to the received API Key from a provisioning system (106), and comparing the fetched current counter value with a provisioned value to determine availability of service based on the comparison;
responsive to the determined availability of service, assigning (806), by the charging function (112), an available service corresponding to the CCR request; and
updating (818), by the charging function (112), the current counter value corresponding to the API Key.
11. The method (800) as claimed in claim 10, further comprising sending a successful response to the BTAS (102) on assigning the available service corresponding to the received CCR request.
12. The method (800) as claimed in claim 10, further comprising sending a fail response back to the BTAS (102), if the charging function (112) fails to find the API Key, or the current counter value corresponding to the service crosses the provisioned value, or validity of user’s plan has expired, or the plan is not active.

13. The method (800) as claimed in claim 10, further comprising establishing a connection with a Session Data Layer (SDL) for storing and retrieving data from a plurality of network functions (NFs) across the communication network.
14. The method (800) as claimed in claim 10, further comprising communicating with a Fault, Configuration, Accounting and Performance (FCAP) manager to perform network management system/element management system -related functions.
15. The method (800) as claimed in claim 10, further comprising generating a charging data record (CDR) for each received CCR request and store information corresponding to each CCR request along with the API key.