Home Blogs Blog: Telecom, IMS, SOA Part 1 SLA: Various ways in how to restrict a Service Provider to send SMSs via OCSG
Part 1 SLA: Various ways in how to restrict a Service Provider to send SMSs via OCSG
Blog - Telecom, IMS, SOA
Written by Jonas W   
Saturday, 07 March 2009 23:06

White list

This blog post require from the reader to be familiar to the OCSG’s Partner Management Model and how to add and modify Service Level Agreements (SLAs). OCSG exposes a northbound ParlayX interface.

I got a question regarding how to utilize OCSG 4.1 policy control via SLA (Service Level Agreement) in Oracle Communications Services Gatekeeper (OCSG) 4.1, known as WebLogic Network Gatekeeper (WLNG) in older releases (WLNG 2.1. WLNG 2.2 and WLNG 3.0).

The issue was how to restrict one ServiceProvider to only send SMS on 5 different numbers. In other words, how to maintain a white list in SLA to accomplish it?

In earlier version of WLNG there was a problem in internal Policy Service with parsing arrays of recipients but that shall now be resolved in OCSG 4.0/4.1. The following is possible to setup on both application and ServiceProvider level.

<methodParameters>
       <methodName>sendSms</methodName>
       <parameterName>arg0.addresses</parameterName>
       <parameterValues>tel:1231231231231 tel:4564564564564</parameterValues>
       <acceptValues>true</acceptValues>
</methodParameters>

The issue on the configuration step was to know how to fetch the addresses array. (If arg0.addresses doesn’t work, try parameters.addresses). Also, please remember to use tel: prefix on addresses.

(Imran Raza Khan, thank you!)

Blacklist

We can also invert the behavior if this restriction. Say that we would like to restrict the provider or application and not let him send SMSs to alarm numbers. In that case, this restriction can be added something like this:

<methodParameters>
       <methodName>sendSms</methodName>
       <parameterName>arg0.addresses</parameterName>
       <parameterValues>tel:112 tel:911</parameterValues>
       <acceptValues>false</acceptValues>
</methodParameters>

 

Restrict TPS

It is also possible to restrict the number of transactions per time unit. This is handled via methodRestrictions element. In the example below we have a complete service contract and we limit the provider to only send 10 requests per 8 second time window. Messages above this rate are rejected. In the example we have also added a day-restriction of maximum 1000 messages, this as a second protection-level.

  <serviceContract>
    <startDate>2001-01-01</startDate>
    <endDate>2099-01-01</endDate>
    <scs>com.bea.wlcp.wlng.px21.plugin.SendSmsPlugin</scs>

    <contract>
      <methodRestrictions>
          <methodRestriction>
              <methodName>sendSms</methodName>
              <rate>
                <reqLimit>10</reqLimit>
                <timePeriod>8000</timePeriod>
              </rate>
             
              <quota>
                <qtaLimit>1000</qtaLimit>
                <days>1</days>
                <limitExceedOK>false</limitExceedOK>
              </quota>
              </methodRestriction>
      </methodRestrictions>
    </contract>

  </serviceContract>

 

Blacklist method

There is also one variant where you can exclude one or several methods from the interface exposed to providers. Only simple way is to use the blacklist method tag. In the example below we restrict the usage of sendSms to network, but the application can still receive text messages, since we don’t have any restriction expressed for this.

   <methodAccess>
          <blacklistedMethod>
              <methodName>sendSms</methodName>
          </blacklistedMethod>
      </methodAccess>

 

More Policy options

You have of course also many other ways that you can restrict and control traffic in OCSG. It’s quite easy to experiment with these, just modify and test!

Here are some samples of what to modify on SP/APP group SLA level:
• Start and end date of the contract.
• Which Service Capabilities the service Provider Group is allowed to use.
• Guaranteed number of requests per time-interval for a specific method.
• Maximum number of requests per time-interval for a specific method.
• Access to individual methods.
• Which currencies to use in the Charging service.
• Possible charging amounts or charging indicators when sending SMSs and MMSs.
• Maximum size of SMSs and MMSs
• Content types to be allowed in MMSs (MIME-types).
• If allowed to listen for mobile originating messages or message delivery notifications.
• If allowed to use USSD or SMS in message based user interaction.
• Maximum number of concurrent voice calls.
• Maximum number of participants in a call (legs).
• Which state transitions (ANSWER , ALERTING , ADDRESS_ANALYSED , etc..) for a call that can be distributed to an application.
• If allowed to read or read and write subscriber profiles.

Comments? Contact This e-mail address is being protected from spambots, you need JavaScript enabled to view it