The Operator Specific Barring Types are 4 operator defined rules that are stored in the AS. The ODB data indicates which of them should be evaluated and, like all others ODB conditions, they take precedence over MMTelICB and MMTelOCB .
What is Operator Specific Barring?
The 3GPP specifications TS 24.315 defines:
The Operator specific barring definition for type 1, type 2, type 3, and type 4 is locally configured in the AS providing the ODB service. For operator specific barring the criteria that can be used by the operator to define conditions that are used to determine whether the category applies may be based on any signalling information from the incoming request. Examples of such criteria are: 1) destination type e.g. international numbers or specific numbers; 2) media used in the communication, e.g. audio, video, or text. |
The scope definition of what kind of conditions can be present in those rules is not specified. The OpenCloud implementation of those rules follows the simservs RuleSet definition (TS 29.364 ) for MMTelICB Supported Barring Rule Conditions and MMTelOCB Supported barring rule conditions. This way the operator can define the same MMTel barring conditions supported by the MMTelOCB and MMTelICB features.
ODB-Specific Conditions
There are conditions that are unique to ODB. These are:
Incoming Communications
To make a rule match on any communications that are 'incoming', add the <incoming /> element to its set of conditions.
Example:
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice-incoming">
<cp:conditions>
<incoming />
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
Outgoing Communications
To make a rule match on any communications that are 'outgoing', add the <outgoing /> element to its set of conditions.
Example:
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice-outgoing">
<cp:conditions>
<outgoing />
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
How to provision the Operator Specific Barring rules
The operator can include the rules in the profile MMTelOdbOperatorSpecificTypesConfigProfileTable.
Attribute Name |
Type |
Default Value |
Description |
Type1 |
String |
null |
The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type1 is |
Type2 |
String |
null |
The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type2 is |
Type3 |
String |
null |
The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type3 is |
Type4 |
String |
null |
The ruleset to be evaluated when the ODB data OperatorSpecificBarring.Type4 is |
Examples
The sections below show XML data stored in the VoLTE profile MMTelOdbOperatorSpecificTypesConfigProfileTable.
The values can be applied for type 1 to type 4. The fact that the <incoming\> and <outgoing\> are not present, means that those rules will
be applied to both directions.
barr video
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="no_video">
<cp:conditions>
<media>video</media>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
barr identity
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-alice">
<cp:conditions>
<cp:identity>
<one id="sip:alice@example.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
barr specific domain for a 1 month period
<cp:ruleset xmlns="http://uri.etsi.org/ngn/params/xml/simservs/xcap" xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="barr-domain">
<cp:conditions>
<cp:identity>
<many domain="example.com"></many>
</cp:identity>
<cp:validity>
<cp:from>2016-01-01T00:00:00</cp:from>
<cp:until>2016-01-31T23:59:59</cp:until>
</cp:validity>
</cp:conditions>
<cp:actions>
<allow>false</allow>
</cp:actions>
</cp:rule>
</cp:ruleset>
