SMS Generation Mechanism is Strongly Recommended for You!

HalfMoon
HalfMoon  Medium  (1)
2 years 8 months ago  View: 9304  Reply: 6

Bothered by monthly traffic and quota exceeding?

Upset for receiving duplicate short messages?

Depressed by receiving unexpected short messages during spare time?

The UPCC Subscriber Notification Manual demystifies policy control principles for you!

Come and get the hang of short message notifications for subscriber consumption!

 

20170320104215577001.png 

 

1.1 Internal processing flow of notifications

The inter-module processing flow of notifications is classified into notification generation, notification suppression, notification sending, and notification resending, as shown in Figure 1.

Figure 1. Internal processing flow of notifications

20170320103935067001.png

 

1.2 Notification Generation

Notifications can be generated in the following three modes:

l  Online service triggering

l  Offline service triggering

l  Service provisioning triggering

The specific triggering flows are as follows:

1.2.1 Online service triggering

 When an online subscriber uses a service, the UPCC determines whether to trigger a notification based on subscriber information obtained from the policy and charging enforcement function (PCEF). For example, if the quota usage or balance reported by the PCEF reaches the preset threshold and the threshold has been configured with a notification, the service process unit (SPU) of the UPCC generates notification contents. Figure 2 shows the flow for notification generation triggered by online services.

Figure 2. Notification triggered by online services

20170320104409164.png

 

1.2.2 Offline service triggering

When a subscriber is in the offline state, the UPCC periodically checks service information about the subscriber. If the UPCC detects that a service or service package subscribed to by the subscriber takes effect or expires and the service or service package has been configured with a notification, the management process unit (MPU) of the UPCC generates notification contents. Figure 3 shows the flow for offline notification generation.

Figure 3 Notification triggered by offline services

20170320104422306.png

 

NOTE:

SET SCANSW and VRM_OFFLINESRVSWITCH collectively determine whether notifications can be triggered by offline services.

1.2.3 Service provisioning triggering

When a subscriber subscribes to or modifies a service through the provisioning system, if the service or service package has been configured with a notification, the MPU of the UPCC generates notification contents. Figure 4 shows the flow for notification generation triggered by service provisioning.

Figure 4 Notification generation triggered by service provisioning

20170320103935034005.png

 

1.3 Notification Suppression

As shown in the notification generation flow, notification suppression is determined by the MPU_MNR module (for the offline scenario) and SPU_MNR module (for the online scenario). The determination mechanisms for notification suppression in online and offline scenarios are the same. Figure 5 uses the online scenario as an example to illustrate the determination mechanism of notification suppression.

Figure 5 Determination mechanism of notification suppression

20170320103935485006.png

 

1.         The SPU determines whether the same notification that does not expire but has not been successfully sent exists in the notification suppression file (P_NotifyRestriction.txt).

a.             Yes: The SPU does not send the notification.

b.             No: Go to step 2.

2.         The SPU determines whether the notification needs to be suppressed.

a.             Yes: Go to step 3.

b.             No: The SPU performs the following operations:

i.  Inserts a new notification record into the notification suppression file (P_NotifyRestriction.txt and sets the RESULT field to Sending.

ii.        Deletes records that have expired and exceed the maximum number of records for each subscriber from the notification suppression file (P_NotifyRestriction.txt.

iii.      Sends the assembled notification to the PMS agent unit (PAU).

3.         Based on the records in the notification suppression file (P_NotifyRestriction.txt, the SPU checks whether the notification type, unique key, and associated notification template are the same between the notification to be sent and the notification that has been sent but does not expire.

a.             Yes: The SPU suppresses the notification to be sent.

b.             No: The SPU sends the notification to the PAU.

NOTE:

Specifically, the SPU can also determine whether to perform repeated notification suppression in a short period based on the setting of BLC_NOTIFYSENDINTERVAL. Set this software parameter if the UPCC is required to suppress two repeated notifications from being generated in a short period. For example, if the receiver is set to the master subscriber for all messages in a scenario where master and subordinate subscribers share the same quota, the master subscriber may receive two repeated notifications. The setting of this software parameter can prevent repeated notification from being sent during a specified period.

1.4 Notification Sending

After a notification is generated, the PAU does not send the notification immediately, but stores the notification to a local NotifyWaitted file (NotifyWaitted_PAUMID_SN.txt) to be sent. The actual time for sending the notification depends on the number of notifications to be sent and the speed for the policy management service (PMS) to send notifications.

The message flow for sending notifications triggered by offline services of the MPU is similar to that for sending notifications triggered by online services of the SPU. Figure 6 shows the principles for sending subscriber notifications triggered by the SPU.

Figure 6 Principles for sending subscriber notifications triggered by the SPU

20170320103935011007.png

 

1.         An SMS notification is triggered when a subscriber uses a service online. For example, when the quota usage of a subscriber reaches the specified threshold and the threshold has associated with an SMS notification, an SMS notification is generated.

2.         The SPU determines whether to suppress the notification. For details about the determination mechanism, see Notification Suppression. If the notification does not need to be suppressed, the SPU records the notification into the notification suppression file (P_NotifyRestriction.txt and sends the notification to the PAU.

NOTE:

l   The SPU sends notifications to multiple activated PAUs in polling mode.

l   The PAU stores notifications to different notification suppression files (P_NotifyRestriction.txt based on the notification types (such as, SMS, email, and SOAP).

l   The VRM_NOTIFYMSGMAXRECORDPERSUB software parameter determines the maximum number of notification records that can be stored for each subscriber.

3.         When the timer configured on the PMS expires, the PMS sends a request to the PAU to obtain notifications to be sent.

4.         The PAU retrieves notifications from the local cache and sends them to the PMS.

NOTE:

l   The PAU also sends configured link information when sending the notifications to the PMS.

l   If the VRM_NTFSENDCONTROL software parameter is set to 1, the PAU checks the size of the resent notification file and changes to the file before retrieving the notifications to be sent and determines whether to continue to send the notifications based on the accumulation status.

5.         The PMS sends the SMS notifications to the SMSC one by one.

6.         After the SMSC sends the notifications to terminals, it returns responses to the PMS.

7.         The PMS sends the sending result to the PAU. Based on the sending result, the PAU updates the notification suppression file (P_NotifyRestriction.txt and historical notification file (NotifyLog_PAUMID.txt).

a.             If the notification is successfully sent, the PAU performs the following operations:

i. Updates the sending time and sets the RESULT field to Success in the notification suppression file (P_NotifyRestriction.txt.

ii.        Records the sending log to the local historical notification file (NotifyLog_PAUMID.txt.

b.             If the notification fails to be sent, the PAU determines whether the notification needs to be resent:

i. If the notification needs to be resent, the PAU updates the sending time and retains RESULT field as Sending in the notification suppression file (P_NotifyRestriction.txt.

ii.        If the notification does not need to be resent, the PAU updates the sending time and sets RESULT field to Fail in the notification suppression file (P_NotifyRestriction.txt. The PAU also records the sending log to the local historical notification file (NotifyLog_PAUMID.txt.

1.5 Notification Resending

For failure notifications that need to be resent, the PAU stores them into the Notity_Resend file (SMS/Email_Resend_PAUMID.txt). The PMS periodically sends a message to the PAU to obtain notifications to be resent. Figure 7  shows the principles for resending notifications.

Figure 7  Principles for resending notifications

20170320103936426009.png

 

1.         When the timer configured on the PMS expires, the PMS sends a request to the PAU to obtain notifications to be resent.

2.         The PAU retrieves notification records to be resent from the Notity_Resend file (SMS/Email_Resend_PAUMID.txt) and sends them to the PMS. A maximum of 100 records can be retrieved each time. The PAU can send notification records to the PMS only when they meet the following conditions:

a.         The interval between the system time and the time when the record was previously sent is greater than or equal to the resending interval specified by Notification resent interval (VRM_NOTIFYRESENDINTERVAL) (the default value is 600 seconds).

b.         The number of resending times of a record does not reach the upper limit specified by Notification resent interval (VRM_NOTIFYRESENDINTERVAL) (the default value is 3).

c.         The interval between the system time and the time when the record was previously sent does not exceed the validity period of a resent notification specified by Resent notification validity period (VRM_NTFRESENDTIMERANGE) (the default value is 43200 minutes).

NOTE:

The PAU also sends configured link information when sending the notifications to the PMS.

3.         The PMS sends notifications to the SMSC one by one based on the time sequence.

4.         After the SMSC sends the notifications to terminals, it returns the sending result to the PMS.

5.     The PMS sends the sending result to the PAU. Based on the sending result, the PAU updates the database and local historical notification file (NotifyLog_PAUMID.txt).

 If you have any suggestion, welcome to provide your feedback and discuss with us. Thanks!

This post was last edited by Tony.Cheng at 2017-03-20 12:14.
nklsureshkumar
nklsureshkumar  Platinum 
2 years 8 months ago
great explanations
Saravanan.S
Saravanan.S  Gold 
2 years 8 months ago
Very well explained
HalfMoon
HalfMoon  Medium 
2 years 8 months ago
Thanks for your approve.
If you have any suggestion, welcome to provide your feedback and discuss with me at any time.
HalfMoon
HalfMoon  Medium 
2 years 8 months ago
Thank you very much. Your approve means a lot for me. It made me know what I did is helpful.
If you have any suggestion, welcome to provide your feedback and discuss with me at any time.
nklsureshkumar
nklsureshkumar  Platinum 
1 year 8 months ago
Excellent document,Keep it up.
user_2837311
user_2837311  Diamond 
1 year 7 months ago
useful document, thanks