Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
D0103v1.doc Version 1 6.7.2003<br />
4.5.4.5.2.3 DSCP<br />
Each flow is associated with a DSCP-Field. In general, there will be at least one flow from the user and<br />
one to the user. In <strong>Moby</strong> <strong>Dick</strong> flows occur always pair wise—one flow to and one flow from the user.<br />
Such a pair of flows has always the same DSCP value. Therefore only one DSCP field is needed.<br />
Within one session there can be an unlimited number of such pair wise flows.<br />
Details:<br />
MySQL data type:<br />
TINYINT UNSIGNED<br />
(Value 0 to 255)<br />
4.5.4.5.2.4 BytesFromUser<br />
Same case as “ToUser”<br />
4.5.4.5.2.5 PacketsFromUser<br />
Same case as “ToUser”<br />
4.5.4.5.2.6 AcctType<br />
Value<br />
Rows (in the same session)<br />
DSCP 1. – n.<br />
Table 34: DSCP<br />
This column defines the type of record: start, interim and end row. This field is used to verify that the<br />
session has been closed before calculation of the charges. The column is defined as enumeration<br />
ENUM(“start”, ”interim”, “end”) .<br />
Details:<br />
4.5.4.5.2.7 DataUsed<br />
Value<br />
Rows (in the same session)<br />
“start”, “interim”, “stop” 1. – n.<br />
Table 35: AccType<br />
This is column that must not be changed by the accounting component. The charging component will use<br />
it for marking a row that has been used for charge calculation. After marking it might be useful to move<br />
the row to a separate database – this move operation will be issued by the charging component. This way,<br />
the accounting database doesn’t get to big.<br />
Details:<br />
MySQL data type:<br />
TINYINT UNSIGNED<br />
(Value 0 to 255)<br />
4.5.4.6 Locking of Accounting Database<br />
Value<br />
Rows (in the same session)<br />
0 or 1 1. – n.<br />
2 to 255 Reserved for future use<br />
Table 36: Data Used<br />
Single updates to the accounting DB are atomic. As the accounting DB consists of two tables—cf. Table<br />
27 and Table 28—it is possible that the CC could access an incomplete or inconsistent entry. Therefore<br />
the AAAC server has to lock the tables until the complete data of an accounting message has been<br />
updated. The locking will be realized by putting MySQL write locks on both tables for the time of the<br />
update. A MySQL write lock prevents read and write access to the tables by any other process.<br />
D0103v1.doc 129 / 168
Change language