Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
4.5.1.2 General View of User Profile
Before talking of user profiles and their definitions, we need to spend some thoughts on the accounting,
charging, customer profiles and SLA’s—since this is all related together. Within the MobyDick project
there will be “MobyDick” -operators offering services to the customers. For such an operator accountingand
charging-components (besides many other components) will be developed. One aim is that roaming
between different “MobyDick”-operators shall be possible. This aim has main influence in developing the
accounting and its components, c.f. section 4.5.3. All accounting data is stored at the AAAC.h—in the
case of roaming (i.e. the customer is in a foreign domain), the accounting data is transferred from the
AAAC.f to the AAAC.h and then stored in the accounting database. The format and structure of the
accounting data is fixed, cf. section 4.5.4.4.
The next step is the SLA between the customer and one of our “MobyDick”-operators. Each user must
have an SLA with at least one operator (called home operator), before he can use a service—this SLA
may include the post- or prepaid billing scenario. Basically each “MobyDick”-operator can setup its own
SLA’s and its own tariff structure. In order to support roaming between operators, the basis for the
charging (and tariffs) will be the accounting data, which has always the same structure (cf. section
4.5.4.4). So, each “MobyDick”operator could use its own charging component and its own tariff
structure, regardless what the other operators will use and roaming would still be possible.
Within the MobyDick-project we need to develop one charging component for a “MobyDick”-operator.
The charging component will be developed at ETH and will then be used for all “MobyDick”-operators,
since no other charging components will be developed. Therefore, all operators will use the same
charging components with the same tariff structure (but not the same tariffs) and hence the SLA’s and the
corresponding parts in the customer profile will have the same structure, too. This is simply due to the
fact that the SLA’s and the charging/tariffing structure are closely related.
This general structure of the SLA’s, i.e. their representations in the customer profiles are shown in Table
20. The customer database containing this data will be realized with MySQL and is always located at the
home “MobyDick” operator.
Some entries in Table 20 should not be transferred to any other “MobyDick”-operator, because the data is
only needed by the charging and/or billing component of the home operator, cf. last column. The first
rows of Table 20 contain information about the user’s address. The row for the remaining budget “RB”
will be used in the future to support the prepaid business case. Here it is important to note that the
remaining budget in monetary units (e.g. € 12.50) must never be transferred to another operator. But the
representation of the remaining budget in terms of “accounting units” (e.g. 120 MB download volume)
needs to be accessible for other operators, since they need to know, when the remaining budget is empty.
The row “Payment scheme” is used to distinguish between the post- and prepaid business case.
The structure of tariffs is as follows:
Within an SLA, each service is associated with a tariff ID. In the accounting process, services can be
distinguished on the basis of the DSCP field, cf. section 4.5.4.3, 4.5.4.4 for details. Because we
distinguish between tariffs in the home and foreign domain, there exists also different tariff ID’s for the
home and foreign domain. As an example “HDTariffS1” would contain the tariff ID for service S1 in the
home domain. Certain values of the tariff ID’s have special meanings, please refer to Table 18.
Values of TariffID’s
Meaning
0 Users is not allowed to use the respective service
according to the SLA
1 Signalling (this might lead to no charge or only a
very small charge)
2 … 9 Reserved for future use
10 … 255 Valid Tariff ID’s of services
Table 18: Values of tariff ID’s.
In order to give further structure in the values of the tariff ID’s, the ranges reserved for selecting the tariff
are shown in Table 19. With this predefined structure it’s possible to setup 5 different tariffs for each
service per domain. For the MobyDick environment this represents enough flexibility.
D0103v1.doc 106 / 168