Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
Moby Dick Consolidated System Integration Plan
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
D0103v1.doc Version 1 6.7.2003<br />
4.5.4.2.9 Interval of “interim” messages<br />
In <strong>Moby</strong> <strong>Dick</strong>, DIAMETER “interim” message are being generated after every 3 minutes 3 .<br />
4.5.4.3 DSCP Values<br />
In <strong>Moby</strong> <strong>Dick</strong>, each service is associated with bandwidth and priority. This two values will be mapped to<br />
a DSCP value. This mapping is fixed and must not be changed later on. The DSCP value will be used to<br />
select the tariffs. There needs to be a mapping from DSCP values to services (with a certain QoS).<br />
Within <strong>Moby</strong> <strong>Dick</strong> we can make the assumptions, that this mapping is static and no services are added<br />
later on. Of course, in a general environment this assumption could not be made.<br />
The DSCP field consists of 6 Bits and is present in every header of an IP packet. Due to implementation<br />
reasons, the DSCP values will be stored in different data types, cf. Table 24.<br />
DSCP Format in<br />
# Bits<br />
Values of Bits<br />
0 1 2 3 4 5 6 7 8 – 15 16 – 31<br />
Meter Component 16 1 2 3 4 5 6 x x x – x –<br />
Accounting Database 32 1 2 3 4 5 6 x x x – x x – x<br />
Charging Database 8 1 2 3 4 5 6 x x – –<br />
Table 24: Representation of DSCP Values; DSCP Bits marked in yellow; “x” are don’t cares<br />
Table 25 shows the mapping from services to DSCP values. It is possible that two different applications<br />
generate flows with the same DSCP values; therefore it is not possible to conclude from an observed flow<br />
(i.e. the accounting data in the DB) to a certain application.<br />
Name<br />
Service<br />
Class<br />
Relative<br />
Priority<br />
Service parameters<br />
Service<br />
Description<br />
DSCP<br />
(binary)<br />
DSCP<br />
(decimal)<br />
S1 EF 1 Peak BW: 32 kbit/s Real time services<br />
101110 46<br />
SIG AF41 2 Unspecified IP signalling only 100010 34<br />
S2 AF21 3 CIR: 256 kbit/s Priority (urgent) data<br />
transfer<br />
S3 AF1* 4 Three drop<br />
precedences (kbit/s):<br />
AF11 – 64<br />
AF12 – 128<br />
AF13 – 256<br />
S4 BE 0 Peak bit rate: 32<br />
kbit/s<br />
S5 BE 0 Peak bit rate: 64<br />
kbit/s<br />
S6 BE 0 Peak bit rate: 256<br />
kbit/s<br />
4.5.4.3.1 Alternatives after charge calculation<br />
Olympic service<br />
(better then BE:<br />
streaming, ftp, etc)<br />
Table 25. Mapping of Services to DSCP values.<br />
010010 18<br />
001010<br />
001100<br />
001110<br />
Best effort 000000 0<br />
Best effort 000010 2<br />
Best effort 000100 4<br />
After the accounting data was used by the charging component, it needs to be marked as “used”.<br />
After this marking of accounting data, there exist two alternatives:<br />
10<br />
12<br />
14<br />
3 There is no scientific reason to set this value to 3 minutes. If it is too small (e.g. 10 seconds) then the accounting DB<br />
would get too big.<br />
D0103v1.doc 124 / 168
Change language