Method of controlling service load by session on a telecommunications charging system

A method of controlling service load by session on a telecommunications charging system includes the following steps:

• Step 1:
• The charging system determines if the system is experiencing an overload;
• this step is done through the following substeps:
• Step 1.1:
• The charging system calculates parameters in each CALCULATION INTERVAL period
• Each time a charging request is received from an external systems, a NUMBER_OF_REQUEST is increased by one unit
• After each CALCULATION INTERVAL period:
• + The charging system recalculates a load of the service at a current time through the formula:
• TPS
• =
• NUMBER_OF
• ⁢
• _REQUEST
• *
• 1000
• CALCULATION
• ⁢
• INTERVAL
• + Update a number of charging requests:
• NUMBER_OF_REQUEST=0
• + Update LIST_OF_STATE_COMPARED_UPPER_THRESHOLD list:
• Compare TPS with UPPER_THRESHOLD value;
• If TPS>=UPPER_THRESHOLD:
• update LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (i)=LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (i-1) with i>0;
• LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (0)=1
• If TPS<UPPER_THRESHOLD:
• update LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (i)=LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (i-1) with i>0;
• LIST_OF_STATE_COMPARED_UPPER_THRESHOLD (0)=0
• + Update LIST_OF_STATE_COMPARED_LOWER_THRESHOLD list:
• Compare TPS with LOWER_THRESHOLD value;
• If TPS>=LOWER_THRESHOLD:
• update LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (i)=LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (i-1) with i>0;
• LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (0)=1
• If TPS<LOWER_THRESHOLD:
• update LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (i)=LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (i-1) with i>0;
• LIST_OF_STATE_COMPARED_LOWER_THRESHOLD (0)=0
• the end of step 1.1 obtains values of variable parameters at a time, which are input for the next processing steps;
• Step 1.2:
• update a overload of the charging system:
• determine the overload status of the chargin system by the following quantitative function:
• f
• (
• StatePrevious
• ,
• ListOfState
• i
• ,
• Threshold
• i
• )
• =
• StatePrevious
• *
• ∏
• i
• =
• 1
• n
• Rule
• i
• the f function takes input parameters:
• + StatePrevious:
• accepts either the value of 0 or 1;
• + ListOfStatei:
• a list of elements that accept either a value of 0 or 1;
• + Thresholdi:
• accepts integer values;
• in which:
• Rulei:
• compare values of the elements in ListOfStatei with 1;
• if ListOfStatei has at least n elements greater than or equal to 1, then Rulei returns the result 1;
• on the contrary, Rulei returns 0;
• the function f returns a result as the product of StatePrevious and the Rulei;
• this product takes either a value of 0 or 1, from the result of the f function, update the state of the charging system accordingly via parameter STATE;
• at the end of step 1.2 specifically and step 1 in general, we can determine whether the charging system is in a normal or an overloaded state at a measurement time;
• Step 2:
• the charging system selectively bypasses or accepts requests according to conditions and state of the sessions;
• the charging system defines through a programming language variable parameters in the following CALCULATION INTERVAL period:
• STT
• Name
• Describe
• 1
• NUMBER_
• Value:
• integer type
• OF_
• Unit:
• request number
• RESPONSE
• Meaning:
• The total number of requests that
• have been processed and responded to the
• external system within a period of
• CALCULATION INTERVAL
• 2
• LOCAL_TPS
• Value:
• integer type
• Unit:
• request number
• Meaning:
• The total number of requests that
• have been processed and responded to the
• external system within a period of one second
• The formula for calculating the internal load
• is as follows:
• LOCAL_TPS
• =
• NUMBER_OF
• ⁢
• _RESPONSE
• *
• 1000
• CALCULATION
• ⁢
• INTERVAL
• based on the above variable parameters, the process of bypassing or accepting a charging request comprises the following steps:
• Step 2.1:
• check the overload status of the charging system (updated through step 1);
• if the system is normal (i.e. not overloaded, STATE=0), the charging request is forwarded to internal applications in the charging system to calculate based on the pre-configured policies;
• if the system is overloaded (STATE=1), perform step 2.2;
• Step 2.2:
• check the information of the charging request;
• check the REQUEST_TYPE of the charging request:
• if the REQUEST_TYPE of the charging request is an Initialization Request (REQUEST_TYPE=1):
• this is the initialization message for a new session, so move to step 2.3 to always bypass;
• If if the REQUEST_TYPE of the charging request is not an Initialization Request (REQUEST_TYPE other than the value 1), move to step 2.6 to check the previously bypassed status of the session;
• Step 2.3:
• store SESSION_ID in a temporary in-memory database;
• store the SESSION_ID (the identifier of the charging session) in the temporary in-memory database and move to step 2.4;
• Step 2.4:
• store the charging request in a persistent database so that an independent charging application can reprocess the bypassed message the storage structure of the request is as follows:
• Description of
• Index
• Field Name
• information
• Data Type
• 1
• SESSION_ID
• Identification of the
• Integer
• session, charging requests
• of the same session have
• the same identifier
• 2
• REQUEST_TYPE
• Charging Request Type
• Integer
• 3
• MSISDN
• Subscribers Id
• String
• 4
• REQUEST_NUMBER
• Charging Message
• Integer
• Sequence Number
• 5
• REQUEST_TIME
• Request Submission
• Integer
• Time
• 6
• USAGE
• Service Usage Volume
• Integer
• 7
• LOCATION
• Subscriber's Location
• String
• 8
• SERVICE_TYPE
• Subscriber Services Used
• Integer
• 9
• CALL_CENTER
• External Call Center
• String
• 10
• . . .
• . . .
• . . .
• after storing, move to step 2.5;
• Step 2.5:
• create a response message with a success error code that has been agreed on with a core network systems, finish processing the charging request;
• Step 2.6:
• check the status of previous bypassed sessions:
• check if the SESSION_ID of the charging request is already in the temporary in-memory database:
• if yes, this charging session has been previously bypassed, move back to step 2.4 to continue bypassing it;
• if no:
• the charging session has not been previously bypassed, move to step 2.7 to check the internal load of the charging system;
• Step 2.7:
• check the internal load of the charging system;
• i LOCAL_TPS<LOWER_THRESHOLD:
• the internal applications of the charging system have not reached the overload threshold, so the charging request will be forwarded to these applications for normal charging processing;
• if LOCAL_TPS>LOWER_THRESHOLD:
• the internal applications of the charging system have exceeded the overload threshold, move the message to step 2.8 to continue checking the REQUEST_TYPE of the message, and simultaneously bypass processing the message;
• Step 2.8:
• check the information of the charging request;
• check the REQUEST_TYPE of the charging request:
• if the information of the charging request is an Update message (feature key REQUEST_TYPE=2):
• this will be a first update request to bypass, so move to step 2.3 to store the feature key and bypass;
• if the information of the charging request is a Termination message (feature key REQUEST_TYPE=3):
• since it is a final message of a charging session, there is no need to store the feature key, so move to step 2.4 to bypass;
• at the end of step 2, we have established which charging messages are processed and which are bypassed, the charging system stores the bypassed charging messages for reprocessing in step 3;
• Step 3:
• the charging system performs analysis and reprocessing of saved charging messages;
• the charging system designed the processing flow for charging requests that have been bypassed (no charging processing) in step 2 as follows:
• Step 3.1:
• automatically determine whether a reprocessing flow is active;
• at each CALCULATION INTERVAL period,
• determine an automatic status of the processing flow through the following quantitative function:
• f
• ⁡
• (
• Tps
• i
• ,
• MaxThreshold
• i
• ,
• PercentageThreshold
• i
• )
• =
• ∏
• i
• =
• 1
• n
• Rule
• i
• the f function takes the input parameters:
• + Tpsi:
• List of elements that are integers
• + MaxThresholdi:
• accepts integer values
• + PercentageThresholdi:
• accepts an integer between 0 and 100
• in which:
• Rulei:
• compare the values Tpsi with
• MaxThreshold
• i
• *
• PercentageThreshold
• i
• 1
• ⁢
• 0
• ⁢
• 0
• If there is
• Tps
• i
• >
• MaxThreshold
• i
• *
• PercentageThreshold
• i
• 1
• ⁢
• 0
• ⁢
• 0
• ,
• return result 1
• Otherwise, Rulei returns 0 results
• the function f returns the result as the product of Rule;, this product takes either a value of 0 or 1, from the result of function f:
• + if f=1:
• the charging system does not need to automatically reprocess the charging;
• continue to check step 3.1 after the CALCULATION INTERVAL interval;
• + if f=0:
• The charging system automatically activates the re-charging flow for the messages stored in the persistent database, move to step 3.2;
• Step 3.2:
• processing the charging requests;
• this step is done through the following substeps:
• Step 3.2.1:
• retrieve a charging request from the persistent database;
• Step 3.2.2:
• check the information of the charging request and transfer it to the normal charging processing flow;
• check the REQUEST_TYPE attribute of the message:
• if it is an Initiation message (attribute REQUEST_TYPE=1):
• send the Initiation charging request to the charging application to process the charging according to the pre-configured policy
• if it is an Update message (attribute REQUEST_TYPE=2):
• send the Update charging request to the charging application to process the charging according to the pre-configured policy
• if it is a Termination message (attribute REQUEST_TYPE=3):
• send the Terminate charging request to the charging application to process the charging according to the pre-configured policy;
• Step 3.2.3:
• wait for a response from the charging application, after receiving the response message, return to step 3.1 to continue determining the status of the re-charging flow;
• at the end of step 3, the charging system has evaluated the internal overload status, if the system is confirmed to be in the normal state, the system reprocesses the charging requests that have been saved in the persistent database.