Disclaimer: These archives are mirrored from smsforum.net in 2007 before the forum got closed. Please only part of the forum is available here.
For any clarifications regarding these archives you can contact us at http://www.telecomspace.com/contact.


+  SMS Forum Online Discussion
|-+  SMS Technologies
| |-+  ANSI-41 (CDMA & TDMA) Related (Moderator: SMS Forum Support)
| | |-+  SMSNOT & Delivery Pending Flag
« previous next »
Pages: [1] Go Down Print
Author Topic: SMSNOT & Delivery Pending Flag  (Read 276 times)
Offline Offline

Posts: 1

« on: March 26, 2007, 18:51:03 UTC »

We have an application, that "pretends to be an MSC" and when it registers to the HLR via the REGistrationNOTification (REGNOT) message, sets the SMS-Address to another vendors system.  This means the SMSC will send any SMS's via SMDPP (or other protocol) to that system.

We regsiter to the HLR, but indicate another SMS_Address in the REGNOT.

Our challenge, is when we are no longer the MSC (either via the HLR sending a REGistrationCANCel (REGCANC) or us sending a MSInactive (MSINACT).   We should communicate back the SMS Message Waiting Indicator.which is derived from the SMS Delivery Pending Flag (SMSDPF).   The problem is its the other system that knows if the flag is set (i.e., the system indicated by the SMS_Address.

Without setting the SMSDPF/SMSWMI flag correctly (i.e, if its always False) the HLR will not notify the SMSC.

What is the typical SMSC behavior in this case?   How long would it typically wait to retry via sending an SMSREQ (SMS Request) to the HLR?

If we always behaved as if the SMSDPF flag is "false" would that be wrong?   

If we defaulted this flag to "true" - the SMSC would be notified - and in some cases would not have any messages to delivery.   This seems acceptable, as then in cases where there were messages to delivery they would delivered more quickly than waiting for the SMSC "retry" timer which is vendor/network specific.

Sr. Member
Online Online

Posts: 54

« Reply #1 on: March 27, 2007, 18:24:14 UTC »

Hi MessageThis

Well that's a fine pickle you've got yourself in...

In general, I wonder how this scheme works - if the real MSC doesn't receive the regnot/subscriber profile (because the HLR responds to your application's REGNOT instead), how does it allow service to the mobile? How about voice calls - where does the ROUTREQ go to?

But assuming you have that sorted out, some specific SMS comments:

- Although the standard is definitely written to allow a different SMS_Address (i.e. what you are exploiting), it is pretty rare. So much so that I have seen HLRs with a statically provisioned association of MSCID to SMS_Address, and heard about others that just use the OPC/CgPA from the REGNOT rather than honouring the SMS_Address parameter. So depending on your HLR, you might need to check that this approach can work at all.

- SMSC retry schedules are typically quite aggressive, but then over time may step back to once every hour etc. Relative to the initial unsuccessful delivery attempt, you don't know when the mobile might be deregistered. You would need to be sure that the SMSC does a new SMSREQ for each retry, rather than just resending the SMDPP to the last known location - I think this is a reasonable assumption. You would also need to check that the SMSC applied its retry schedule even if CauseCode = Postponed was returned from the MSC.

- I think including the SMSMWI in every MSINACT/regcanc seems like a pretty good idea. The SMSC should be able to cope with receiving an SMSNOT when there is no message.

- Another alternative might be to include your application "in-line" for the SMDPP/smdpp path. I.e. set the SMS_Address to your own address, then forward the SMDPP on to the true MSC. Then you will see the return result and know what's going on with the SMSDPF.


Pages: [1] Go Up Print 
« previous next »
Jump to:  

Login with username, password and session length