Creating Custom Service Life Cycles

8 Creating Custom Service Life Cycles

Learn how to use custom life cycles to manage service status at a detailed level in Oracle Communications Billing and Revenue Management (BRM). For example, you can use statuses such as Dormant, Credit Expired, and Fraud Investigated to indicate the exact state of a service and control how the service is used.

Topics in this document:

About Custom Service Life Cycles

By default, all BRM service types use the following statuses: Active, Inactive, and Closed. If you need a life cycle that better represents the phases of a particular service type, create a custom service life cycle for that service type. For example, you might create the following custom life-cycle states:

Preactive to indicate a service that is ready to activate, but not yet activated.
Fraud Investigated to indicate a service that is under investigation.
Dormant to indicate a service that hasn't been used for a specified amount of time.

Custom service life cycles can contain any number of states and state transitions. For each state, you can specify the following:

The states to which the state can change
The actions that occur before and after a state transition takes place
Rules to validate requests received in the state

You can associate custom life cycles with any BRM service type.

To create custom life cycles, you edit and load the config_lifecycle_states.xml file. By default, the file contains a sample prepaid service life cycle, which you can use as is, modify, or delete. See "About the Sample Prepaid Service Life Cycle" for more information.

Note:

The default service life cycle status is stored in the PIN_FLD_STATUS field in /service objects. The custom service life cycle state is stored in the PIN_FLD_LIFECYCLE_STATE field of /service objects.

Triggering State Changes in Custom Service Life Cycles

The state of a service changes as the result of actions or conditions that affect the service. The actions can be triggered manually or automatically.

In custom service life cycles, state changes can be triggered by the following:

CSRs: Using Billing Care or Customer Center, a customer service representative (CSR) can manually perform any permitted state change. Such changes are defined in the <TRANSITIONS> child element of the <STATES> element in the config_lifecycle_states.xml file.
Any action that impacts a service balance: After a balance is adjusted or topped up, the PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE policy opcode triggers any required service state changes and updates the state expiration date (PIN_FLD_SERVICE_STATE_EXPIRATION_T field) in the /service object based on the new state's expiration period.

If you create your own custom service life cycles, you can modify this policy opcode to trigger state changes based on different criteria.
pin_state_change: This utility performs bulk service state changes based on the state expiration time (PIN_FLD_SERVICE_STATE_EXPIRATION_T field in /service objects).

A system administrator schedules the utility to run at a specified time each day. When the utility finds services whose state expires on the current date, it changes that state to its default next state.

Note:

The default next state is specified in the <TRANSITIONS> element whose <DEFAULT_FLAG> is set to 1. If this flag is not set to 1 in any of the transitions configured for a state, this utility does not change the state.

See "pin_state_change" for more information.

Configuring Business Rules for Custom Service Life Cycles

For each life-cycle state, you can configure business rules to validate the actions that subscribers try to perform in the state.

You configure business rules in the <RULES> child element of the <STATES> element in the config_lifecycle_states.xml file. In that file, each business rule includes the following elements:

<MODULE>: The name of the facilities module (FM) that uses the rule. (The rule is coded in the FM).
<NAME>: The name of the rule as it appears in the FM.
<VALUE>: A value that indicates whether the business rule is enabled or disabled for the state.

To create and use a custom business rule:

Code the validation logic for the new rule in the appropriate policy opcode.
Include a name for the rule in the policy opcode.
Configure a <RULES> element for the rule in the appropriate service life cycle state.

About Creating Custom Service Life Cycles

In addition to defining and loading custom life cycles, you need to do the following:

Enable customer service life cycles in BRM. See "Enabling BRM to Use Custom Service Life Cycles".
Add SLM entries to the Connection Manager (CM) pin.conf file. See "Adding SLM Entries to the CM pin.conf File".
Map each state in the custom service life cycle to a status in the default service life cycle. See "Mapping States to Statuses".
Associate one or more services with the custom service life cycle. See "Associating Services with Custom Life Cycles".
Associate account bill units (/billinfo objects) with the SLM business profile. See "Associating Bill Units with the SLM Business Profile".

Creating Custom Service Life Cycles

To create a custom service life cycle:

Open the config_lifecycle_states.xml file in an XML editor or a text editor.

By default, the file is in the BRM_home/sys/data/config directory.

Note:

The config_lifecycle_states.xml file can contain multiple service life cycle configurations. In the XML file, each life cycle configuration is identified by its <NAME> element. When the content of the XML file is loaded into the BRM database, each life cycle configuration is put into a separate /config/lifecycle_states object.
Add a <ConfigObject> element to the <ObjectList> element.
In the <ConfigObject> element, specify values for the life cycle elements.
Save and close the file.
Open the BRM_home/apps/load_config/pin.conf file.
Add the following line to enable validating the customer life cycles:
```
- load_config validation_module libLoadValidSLM LoadValidSLM_init
```
Save and close the pin.conf file.
Run the following command, which loads the config_lifecycle_states.xml file:
```
load_config config_lifecycle_states.xml
```
If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file.
Stop and restart the CM.

Modifying Custom Service Life Cycles

To modify a custom service life cycle:

Open the config_lifecycle_states.xml file in an XML editor or a text editor.

By default, the file is in the BRM_home/sys/data/config directory.
Modify the <ConfigObject> element in which the life cycle is configured.

Note:

If you change the <NAME> element of a life cycle that services are using, you must update the value of the lifecycle_obj key in those services' validation templates in the pin_slm_business_profile.xml file. You must then reload that file.

For details about editing and loading pin_slm_business_profile.xml, see "Associating Services with Custom Life Cycles".
Set the configMode attribute of the <ObjectList> element to one of the following values:
- replace: Updates the existing /config/lifecycle_states objects. This is the default.
- recreate: Deletes the existing /config/lifecycle_states objects and creates new objects.
Save and close the file.
Run the following command, which loads the modified config_lifecycle_states.xml file:
```
load_config config_lifecycle_states.xml
```
Note:
- The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility. The pin.conf file must also contain the following entry, which enables the utility to validate the XML file values.
```
- load_config validation_module libLoadValidSLM LoadValidSLM_init
```
- If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file.
The utility converts the XML file into one or more /config/lifecycle_states objects, depending on the number of <ConfigObject> elements in the XML file. Each object contains the life cycle defined in one <ConfigObject> element.
Stop and restart the CM.

Enabling BRM to Use Custom Service Life Cycles

To use custom service life cycles, you must run the pin_bus_params utility to change the SubscriberLifeCycle business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

To enable BRM to use custom service life cycles:

Go to BRM_home/sys/data/config.

Create an XML file from the /config/business_params object:

pin_bus_params -r BusParamsCustomer bus_params_customer.xml

In the file, change disabled to enabled:

<SubscriberLifeCycle>enabled</SubscriberLifeCycle>

Save the file as bus_params_customer.xml.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_customer.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

Adding SLM Entries to the CM pin.conf File

To support custom service life cycles, BRM needs the following entries in the CM pin.conf file:

- cm_cache fm_bill_utils_business_profile_cache
- cm_cache fm_bill_template_cache
- cm_cache fm_cust_lifecycle_config_cache
- cm_cache fm_cust_statemap_config_cache

If these entries are not in your CM pin.conf file, you must add them.

To add the CM pin.conf entries for custom service life cycles:

Open the CM configuration file (BRM_home/sys/cm/pin.conf).
Add the following entries to the pin.conf file:
```
- cm_cache fm_bill_utils_business_profile_cache number_of_entries, cache_size, hash_size
- cm_cache fm_bill_template_cache number_of_entries, cache_size, hash_size
- cm_cache fm_cust_lifecycle_config_cache number_of_entries, cache_size, hash_size
- cm_cache fm_cust_statemap_config_cache number_of_entries, cache_size, hash_size
```
where:
- number_of_entries is the following:
  - For fm_bill_utils_business_profile_cache, the total number of business profiles (/config/business_profile objects), including service life cycle business profiles, you plan to create in your system. See "Associating Services with Custom Life Cycles" for more information.
  - For fm_bill_template_cache, the total number of service validation templates (/config/template/service objects), including those defined in service life cycle business profiles, you plan to create in your system. See "Associating Services with Custom Life Cycles" for more information.
  - For fm_cust_lifecycle_config_cache, the number of /config/lifecycle_states objects you plan to create in your system. Each object represents one custom service life cycle. See "Creating Custom Service Life Cycles" for more information.
  - For fm_cust_statemap_config_cache, the number of /config/service_state_map objects you plan to create in your system. The only valid value is 1. See "Mapping States to Statuses" for more information.
- cache_size is the sum of the sizes of the cached objects in bytes.
- hash_size is the square root of number_of_entries.
Save and close the file.
Stop and restart the CM.

Mapping States to Statuses

Each service life cycle state must be mapped to a status (Active, Inactive, or Closed) in the default service life cycle. This mapping supports the following:

Backward compatibility
Custom service state changes triggered by account status changes
Member service state changes triggered by subscription service status changes

Note:

You should not include both services that use the default service life cycle and services that use a custom service life cycle in a service group. If you do, the subscription service might be inactive while a member service is active.

A state can be mapped to only one status.

A status can be mapped to multiple states.

To create state-to-status mapping for the states in all your custom service life cycles, edit the service state mapping configuration file (BRM_home/sys/data/config/config_service_state_map.xml). See "About the Service State Mapping Configuration File" for more information.

After editing the configuration file, use the load_config utility to load the file's contents into the /config/service_state_map object in the BRM database. That object contains the state-to-status mapping for every custom service life cycle in your system. See "Mapping States to Statuses" for more information.

About the Default State of a Status

Consider the following situation:

BRM needs a state for a service that uses a custom life cycle.
Only the service status is known.
The status is mapped to multiple states.

In this situation, BRM uses the status's default state, which is the state whose PIN_FLD_DEFAULT_FLAG field is set to 1 for that status in the /config/service_state_map object.

For example, suppose the Active (10100) status is mapped to the Active, Recharge Only, and Credit Expired states. If a state value is required for a service whose status (Active) is known but whose state is unknown, BRM uses the state in the PIN_FLD_STATES array of the /config/service_state_map object that contains the following values:

PIN_FLD_DEFAULT_FLAG = 1
PIN_FLD_STATUS = 10100

Note:

When a status is mapped to multiple states, the default flag of only one of those states can be set to 1.
Every service life cycle state defined in your system must have a transition to each status's default state. This enables BRM to complete a state transition when only the status to which the service must change is known. For example, if BRM receives a request to change a status from Active to Inactive and the current state of the service is Recharge Only, a transition from Recharge Only to Suspended (the default state for the Inactive status) must exist. If the transition is not defined, the transaction fails.

State transitions are defined in the config_lifecycle_states.xml file. See "Creating Custom Service Life Cycles" for more information.

About the Service State Mapping Configuration File

You configure the state-to-status mapping for the states in all your custom service life cycles in the BRM_home/sys/data/config/config_service_state_map.xml file.

The mapping for each service life cycle state in your BRM system is configured in a <States> element, which has the following syntax:

<ObjectList>
   <ConfigObject>
      <DESCR>Description</DESCR>
      <NAME>Name</NAME>
      <STATES elem="0">
         <DEFAULT_FLAG>DefaultFlag</DEFAULT_FLAG>
         <LIFECYCLE_STATE>LifeCycleStateNumber</LIFECYCLE_STATE>
         <STATUS>StatusNumber</STATUS>
         <STATUS_FLAGS>StatusFlagNumber</STATUS_FLAGS>
      </STATES>
   </ConfigObject>
</ObjectList>

Table 8-1 lists the elements of the preceding syntax:

Table 8-1 Service State Mapping Elements

XML Element	Description	Notes
DESCR	(Optional) Character string that describes the state-to-status mapping.	Minimum length is 0 characters. Maximum length is 255 characters.
NAME	Character string used as the name of the mapping.	The name must be unique within your BRM system. Minimum length is 1 character. Maximum length is 255 characters.
STATES	Parent element of the child elements that map a state to a status. This element is mapped to the PIN_FLD_STATES array in the /config/service_state_map object. The array must contain all the service life cycle states in your system. It can contain states from multiple service life cycles. See "Mapping States to Statuses".	If you configure multiple <STATES> elements, the integer value of each element's elem attribute must be different. The values do not have to be sequential, and they have no relationship to the values of the elem attributes of other elements.
DEFAULT_FLAG	Integer that specifies whether this is the default state for the status to which it is mapped. A status can be mapped to multiple states, but only one of those states can be the status's default state. If a state is required when only a status value is available, BRM uses the default state for that status.	Specify one of the following values: 1: Default state. If multiple states are mapped to a status, only one of those states can have this value. 0: Not the default state.
LIFECYCLE_STATE	Integer that specifies the numeric ID of a custom service state.	Specify the unique ID of the custom service state to which this mapping applies. This ID is configured in the config_lifecycle_states.xml file.
STATUS	Integer that specifies the numeric ID of the status in the default service life cycle to which this mapping applies.	Specify one of the following status IDs: 10100: Active 10102: Inactive 10103: Closed
STATUS_FLAGS	Integer that specifies the status flag to pass when a state change occurs. The status flag specifies the reason for the change.	When a service is reactivated, the value must match the value used in the previous state change. Note: STATUS_FLAGS values are listed in the BRM_home/include/pin_cust.h file.

Mapping States to Statuses

Note:

A custom life cycle state should not be mapped to more than one status. Each status, however, can be mapped to multiple states.

To create state-to-status mapping:

Open the config_service_state_map.xml file in an XML editor or a text editor.

By default, the file is in the BRM_home/sys/data/config directory.
Add a <States> element to the <ConfigObject> element.
In the <ConfigObject> element, specify values for the elements listed in Table 8-1.
Save and close the file.
Run the following command, which loads the changes into the /config/service_state_map object in the BRM database:
```
load_config config_service_state_map.xml
```
Note:
- The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
- The pin.conf file must contain the following entry, which enables the utility to validate the XML file values:
```
- load_config validation_module libLoadValidSLM LoadValidSLM_init
```
- If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
```
- load_config BRM_home/sys/data/config/config_service_state_map.xml
```
The utility converts the XML file into one /config/service_state_map object.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.

For information about reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM.

Modifying State-to-Status Mapping

To modify state-to-status mapping:

Open the config_service_state_map.xml file in an XML editor or a text editor.

By default, the file is in the BRM_home/sys/data/config directory.
Modify the <States> element in which the mapping is configured.

See Table 8-1 for more information about the elements of state-to-status mapping.
Set the configMode attribute of the <ObjectList> element to one of the following values:
- replace: (Default) Updates the existing /config/service_state_map objects.
- recreate: Deletes the existing /config/service_state_map objects and creates new objects.
Save and close the file.
Run the following command, which loads the changes into the /config/service_state_map object in the BRM database:
```
load_config config_service_state_map.xml
```
Note:
- The "load_config" utility needs a configuration (pin.conf) file in the directory from which you run the utility.
- The pin.conf file must contain the following entry:
```
- load_config validation_module libLoadValidSLM LoadValidSLM_init
```
  This entry enables the utility to validate the XML file values.
- If you do not run the utility from the directory in which the configuration file is located, include the complete path to the file. For example:
```
load_config BRM_home/sys/data/config/config_service_state_map.xml
```
The utility converts the XML file into one /config/service_state_map object.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.

For information about reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM.

Deleting State-to-Status Mapping

To delete the state-to-status mapping from your BRM system, use the following load_config command:

load_config -r service_state_map

Caution:

Do not delete mapping that a service is using. Doing so will cause data corruption.

This command deletes the /config/service_state_map object from your BRM database.

See "load_config" for more information.

Associating Services with Custom Life Cycles

A service type (/service subclass object) can be associated with only one life cycle. By default, all service types use the default service life cycle.

To associate a service type with a custom service life cycle, add the following key-value pair to that service's validation template in the SLM business profile:

Key: lifecycle_obj
Value: Name of the custom service life cycle

The SLM business profile is configured in the pin_slm_business_profile.xml file.

Caution:

After a service type is in use in your BRM system, do not associate it with a different life cycle. If you do, state and status changes might fail and data might be corrupted.

See "Creating and Managing Business Profiles" for general information about business profiles.

To associate a service type with a custom life cycle:

Open the pin_slm_business_profile.xml file in an XML editor or a text editor.

By default, the file is in the BRM_home/sys/data/config directory.
In the list of validation template IDs (<TemplateID> elements), add or delete the name and type of the validation template for the appropriate service.

By default, this business profile contains these validation template IDs:
```
<TemplateId name="ServiceTelcoGprs" type="/service/telco/gprs" />
<TemplateId name="ServiceTelcoGsm" type="/service/telco/gsm" />
<TemplateId name="ServiceTelcoGsmTel" type="/service/telco/gsm/telephony" />
```
See "Defining Business Profiles" for more information about <TemplateID> elements.
In the list of key values (<NameValue> elements), add or delete key-value pairs to identify the bill units that belong to this business profile.

See "Defining Business Profiles" for more information about <NameValue> elements.
In the list of validation templates (<TemplateList> parent element), add or delete the definition of the validation template (<Template> element) for the appropriate service.
Save and close the file.
Create a /config/template/service subclass for each service type in the list of validation template IDs (<TemplateID> elements) of the slm_business_profile.xml file.

For example, to support the SLM business profile, create the following subclasses:
- /config/template/service/telco/gprs
- /config/template/service/telco/gsm
- /config/template/service/telco/gsm/telephony
Run the following command, which loads the SLM business profile into a /config/business_profile object in the BRM database:
```
load_pin_business_profile pin_slm_business_profile.xml
```
Note:
- The load_pin_business_profile utility needs a configuration (pin.conf) file in the directory from which you run the utility.
- If you do not run the utility from the directory in which the XML file is located, include the complete path to the file. For example:
```
load_pin_business_profile BRM_home/sys/data/config/pin_slm_business_profile.xml
```
See "load_pin_business_profile" for more information.
The PIN_FLD_NAME field in the /config/business_profile object containing the SLM business profile is set to SLM.
Read the updated object with the testnap utility's robj command or with Object Browser to verify that all fields are correct.

For information about reading an object and writing its contents to a file, see "Reading an Object and Writing Its Contents to a File" in BRM Developer's Guide.
Stop and restart the CM.
(Optional) Make the SLM business profile your system's default business profile. See "Associating Bill Units with the SLM Business Profile".

Associating Bill Units with the SLM Business Profile

For an account to own a service that uses a custom life cycle, the account's bill unit must be associated with the business profile in which the service is linked to the custom life cycle (see "Associating Services with Custom Life Cycles").

By default, services are linked to custom life cycles in the SLM business profile. You can associate an account's bill unit with the SLM business profile in either of the following ways:

Make the SLM business profile your system's default business profile. In this case, when an account is created, its bill unit is automatically associated with the default business profile. To enable this feature, run the pin_bus_params utility to change the DefaultBusinessProfile business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.
If the SLM business profile is not the system's default business profile, you can associate the SLM business profile with the bill unit after the account is created. See "Changing a Bill Unit's Business Profile" in BRM Opcode Guide for more information.

To make the SLM business profile your system's default business profile:

Go to BRM_home/sys/data/config.

Create an XML file from the /config/business_params object:

pin_bus_params -r BusParamsBilling bus_params_billing.xml

In the file, change this element value to SLM (the name of the business profile configured in (pin_slm_business_profile.xml):
```
<DefaultBusinessProfile>SLM</DefaultBusinessProfile>
```
Save the file as bus_params_billing.xml.
If the name of your service life cycle business profile is not SLM, do the following:
1. Open the bus_params_billing.xsl file in an XML editor or a text editor.
  
  By default, the file is in the BRM_home/xsd directory.
2. Search the file for the following section:
```
<xsl:template match="bc:DefaultBusinessProfile">
```
3. In the following lines of that section, replace SLM with the name of your service life cycle business profile:
```
<xsl:when test="normalize-space(text()) = 'SLM'">
<xsl:text>SLM</xsl:text>
```
  For example, if the profile is named XYZ, the lines should look like this:
```
<xsl:when test="normalize-space(text()) = 'XYZ'">
<xsl:text>XYZ</xsl:text>
```
4. Close and save the file.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_billing.xml
```
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.

About the Sample Prepaid Service Life Cycle

Note:

The sample prepaid service life cycle performs charging on specific charge configurations.

The default service life cycle configuration file (config_lifecycle_states.xml) contains a sample life cycle for prepaid services. The life cycle has the following states:

Preactive: The starting state of the sample prepaid service life cycle. This state indicates that the subscriber has never used the service. Typically, the service is provisioned in this state.
Active: A service automatically changes to this state when the subscriber first uses the service by making a call or sending an SMS. In this state, the service start date is set, and the subscriber can perform normal service activity.

The length of time a service is active depends on its balance, usage, and plan type. If the balance reaches its credit limit or if the Active state expires, the service state automatically changes to Recharge Only.
Recharge Only: An active service automatically changes to this state when its balance reaches its credit limit. In this state, the subscriber can receive calls and use free aspects of the service but cannot make prepaid calls. The subscriber can use top-ups to replenish the balance. If the subscriber does not replenish the balance before the state expires, the state changes to Credit Expired.
Credit Expired: A service automatically changes to this state when its Recharge Only state expires. In this state, the subscriber cannot make or receive calls. If this state expires, the state changes to Suspended.
Dormant: Enables service providers to identify unused subscriptions and to offer subscribers incentives to resume using their services. A CSR must set this state manually through Customer Center. A dormant service has the same available features as an active service. If a subscriber uses a dormant service, its state automatically changes to Active.
Fraud Investigated: The service's account is being examined for evidence of fraudulent activity. A CSR must set this state manually through Customer Center. In this state, the subscriber cannot make or receive calls. This state can be changed to Active or Closed.
Suspended: Implies that the subscriber intends to resume the service. In this state, no aspect of the service can be used. A subscriber might ask a CSR to suspend a service while she is on vacation or if she loses her mobile prepaid handset.
SuspendedActive: Allows you to continue charging the subscriber during suspension. This state can be changed to Active.
Closed: The final state of the sample prepaid service life cycle. In this state, no aspect of the service can be used.

About Triggering Sample Prepaid State Changes

Table 8-2 lists the triggers that initiate state changes in the sample prepaid service life cycle.

Table 8-2 Triggers for State Changes in the Sample Prepaid Service Life Cycle

Trigger	Change Performed By	From State	To State
Balance reaches credit limit	PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE	Active	Recharge Only
Balance replenished	PCM_OP_BAL_POL_CHECK_LIFECYCLE_STATE	Recharge Only or Credit Expired	Active
State expires	pin_state_change utility or CSR	Recharge Only	Credit Expired
State expires	pin_state_change utility or CSR	Credit Expired	Suspended
State expires	pin_state_change utility or CSR	SuspendedActive	Active
State expires	pin_state_change utility or CSR	Suspended	Closed
Fraudulent activity suspected	CSR	Active	Fraud Investigated
Fraudulent activity not found	CSR	Fraud Investigated	Active
Fraudulent activity found	CSR	Fraud Investigated	Closed
State expires	pin_state_change utility or CSR	Active	Recharge Only

For an overview of state-change triggers, see "Triggering State Changes in Custom Service Life Cycles".

About the Sample Business Rules

The sample prepaid service life cycle includes the following business rules:

REQ_ALLOWED: Specifies whether a data usage request is allowed. If it is set to Yes, the other two sample business rules are evaluated before BRM determines whether to authorize or reject the request. If it is set to No or not set, the other two sample business rules are ignored and the request is rejected.
MO_ENABLED: Specifies whether mobile-originated calls are allowed. Values are Yes and No. This rule can also apply custom rules that you configure.
MT_ENABLED: Specifies whether mobile-terminated calls are allowed. Values are Yes and No. This rule can also apply custom rules that you configure.

When these rules are loaded into a /config/lifecycle_states object, they are combined into one rule named CALL_ALLOWED, whose values represent various combinations of the values of all three of the preceding rules. Table 8-3 shows the CALL_ALLOWED values for the sample prepaid service life cycle.

Table 8-3 CALL_ALLOWED Values for the Sample Prepaid Service Life Cycle

CALL_ALLOWED Value	MT_ENABLED	MO_ENABLED	REQ_ALLOWED
0	No	No	No
1	No	No	Yes
2	No	Yes	No
3	No	Yes	Yes
4	Yes	No	No
5	Yes	No	Yes
6	Yes	Yes	No
7	Yes	Yes	Yes

For an overview of business rules and information about creating custom business rules, see "Configuring Business Rules for Custom Service Life Cycles".

About the Sample Service State-to-Status Mapping

The default config_service_state_map.xml file contains the mappings shown in Table 8-4, which support the sample prepaid service life cycle.

Table 8-4 State-to-Status Mapping for the Sample Prepaid Service Life Cycle

<LIFECYCLE_STATE>	<DEFAULT_FLAG>	<STATUS>
101 (Preactive)	0	10102 (Inactive)
102 (Active)	1	10100 (Active)
103 (Recharge Only)	0	10100 (Active)
104 (Credit Expired)	0	10100 (Active)
105 (Dormant)	0	10100 (Active)
106 (Fraud Investigated)	0	10100 (Active)
107 (Suspended)	1	10102 (Inactive)
108 (Closed)	1	10103 (Closed)
109 (SuspendedActive)	1	10100 (Active)

See "Mapping States to Statuses" for more information on service state-to-status mapping.

CALL_ALLOWED Value	MT_ENABLED	MO_ENABLED	REQ_ALLOWED
0	No	No	No
1	No	No	Yes
2	No	Yes	No
3	No	Yes	Yes
4	Yes	No	No
5	Yes	No	Yes
6	Yes	Yes	No
7	Yes	Yes	Yes

CALL_ALLOWED Value	MT_ENABLED	MO_ENABLED	REQ_ALLOWED
0	No	No	No
1	No	No	Yes
2	No	Yes	No
3	No	Yes	Yes
4	Yes	No	No
5	Yes	No	Yes
6	Yes	Yes	No
7	Yes	Yes	Yes

CALL_ALLOWED Value	MT_ENABLED	MO_ENABLED	REQ_ALLOWED
0	No	No	No
1	No	No	Yes
2	No	Yes	No
3	No	Yes	Yes
4	Yes	No	No
5	Yes	No	Yes
6	Yes	Yes	No
7	Yes	Yes	Yes