Volume of data: Rating could also be based on volume of data. That is the rate would be applied on per packet or per byte basis. This could be extended to specifying usage limits and incremental rates based on usage volume. After the value of attributes to be rated are identified, the next step in rating is to look up the rate table for applying the rate against the value of the attribute. The rate tables corresponding to different rate plans are identified using the unique rate table ID. Once the value of attribute value and rate is identified, next the event charge is computed. From the event charge the final charge is then calculated by applying discounts, taxes, promotions, and other parameters that impact the final bill to customer but may not be directly linked to usage. Let us now take a specific example of how a call is rated. The following are the high level steps: 1. Determine originating charge point: The originating point would include the country code, city code, and exchange number. The originating cell site address is identified in this step. 2. Terminating charge point: The terminating cell site address is computed where the terminating number will also be a combination of country code, city code, and exchange number. 3. Determine the duration of the call. 4. Determine the rate plan to be applied. The band could be based on networks (fixed or mobile), TOD, DOW, terminating network, and SO on. 5. Based on the rate plan, the rate table lookup is done. This could be based on the rate table ID assuming the table id can identify specific plans. 6. Apply the rate plan on the usage to compute the rate. 7. Apply any other charges like discounts on the rate to determine the customer payable for the call. In short, rating mainly loads the transactions, does a lookup on external data, then applies the business rules and routes the rated transactions to accounting for bill settlement. Figure 20.17 shows that the interaction of other OSS modules with rating engine. Some of the key players developing stand-alon