Service policies determine how devices connect with and interact with your network when using voice, data, and messaging services. Three types of service policies, voice, data, and messaging, each have configurable policy elements specific to each service type.
Service policies contain one or more components. Components combine policy events with filters. Policy events in a component are evaluated only when a filter matches an event or situation. Think of service policies like firewalls. For example, a data service policy allows network access by a device based on configurable items, such as ports and connection type, that are configured in the policy events.
Service policies come in 2 forms. They can be self-contained entitles that are added to network features (and more than one service policy can be added to a network feature) and they are a type of eCommerce policy.
ItsOn Service Design Center offers 3 types of service policies: data, voice, and messaging. The policy types differ in their filter and policy event criteria. When components (associated filters and policy events) are added to a service policy, the filter criteria are data-, voice-, or text-specific. The criteria you can add to policy events in the different types of service policies are the same in each type of service policy, except that Network Type and App Visibility are not criteria that can be added to voice and message service policies.
USSD (unstructured supplementary service data) service is a GSM-only protocol that allows devices to communicate with carrier computers that are dedicated to receiving and processing USSD messages. USSD messages begin with an asterisk (*), a pound sign (#), or a combination of an asterisk and a pound sign (*#), followed by numerical digit combinations that represent commands or data. Groups of digit combinations may be separated by additional asterisks, which allows multiple commands to be sent at once. A USSD message is terminated by a pound sign (#).
USSD service policies are specifically configured voice and messaging policies. The configuration that makes a voice or messaging service policy a USSD service policy is a filter with a Remote Phone Number criterion containing a regular expression that matches the USSD format.
A good example of service policy use would be to create app whitelists and blacklists. For example, you might want to ensure that certain apps can access your cellular network, and prevent others apps from doing so. In a data service policy, you might add and configure two components, one for the whitelist and one for the blacklist. In the whitelist component, you would add filters, each with an app you want to allow, and then in the blacklist component, you would similarly add filters, each with an app you want to block. In the policy event for the former, you would set the action to allow. For the latter, you would choose the block action.
Another example might be if you want some allowed apps to access only your home network, you could create two different allow components, similar to the first example, but more specificity based on location. One contains filters with apps that you want to allow access on any cellular network, as above. The second allow component would contain filters with apps that you want to allow access only on your home network. So you would add your home network group to the IN network group field of the policy event in that component.
For USSD service policies, the configuration will often be somewhat simple. You will want only one component in either a voice or messaging service policy with only the action set to Block. This means that anytime the filter matches, it will block the device action. You then add a filter, add a Remote Phone Number criteria to the filter, and enter a regular expression. For example, you use the command *3282# to mean data usage or text usage. Enter the regular expression ^\*3282#$ to match that command.
You could also create a more robust set of policies for USSD management. The first thing you would need to do is create a regular expression that matches any possible USSD command, including multiple commands sent in one string. Then you could create a feature with 2 service policies. One is a voice service policy with a single component. The component has a filter with 2 criteria. One criterion is Remote Phone Number and contains the regular expression for all USSD. The second criterion is direction, which you would set for outbound. This allows all managed devices to send USSD commands by voice. The second service policy is a messaging policy, again with one component. You add the same criteria, except in this policy, you set the direction as inbound. This allows all managed devices to receive USSD via text messaging. For both policies, you just select allow in the component policy event.