Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
4.5.4.2.3 Re-Authentication, “Authorization-Lifetime”
After 5 minutes the RE-authentication takes place. The session and hence the sessionID will not change.
4.5.4.2.4 Duration of a Session, “Session-Lifetime”
Each session is associated with a lifetime, which is defined during the AA-phases. The correspondent
DIAMETER Parameter (“Session-Lifetime”) has to be set to a reasonable value. In Moby Dick, this
lifetime will be set to 30 minutes, as it is the case in the GSM standard. After expiring, the AAAC client
must generate a DIAMETER “end” message with the according entry in the accounting DB—since the
current session is terminated and the user is disconnected.
4.5.4.2.5 Charging of “open” Sessions
As described in the section 5.2.6.1, the CC will contact the accounting database periodically. All open
sessions—i.e. sessions without the last mandatory row (the one generated after a DIAMETER “end”
message)—are not used for the charge calculation. It is important to note, that all open sessions need to be
closed finally.
If—due to an error or failure —DIAMETER “end” messages are missing in the accounting DB, then the
AAAC home server has to create the “end” row, i.e. it needs to close the open session.
When the AAAC server is started or restarted it checks whether all sessions have an “end” entry and if
not generates one from the latest entry. This latest entry can be an “interim” or “start” message. The first
case is an indication of lost “interim” messages—the AAAC home server can simply duplicate the last
“interim” message belonging to the open session. The latter case indicates that only the DIAMETER
“start” message was written to the accounting DB. And hence, only “null” values were written to the DB
for this session. In this case the AAAC home server will also duplicate this “start” message and will
generate the “end” message, which will of course contain “null” values only. The CC can detect such
“null” sessions in the charging process and ignores them.
4.5.4.2.6 Definition of Session ID
The session ID is generated in the AR (by the AAAC Client) and has the following structure:
;
An example is: “access-router1.ethz.ch;1234” 2
For a detailed description, see section 4.5.4.5.1.2.
The domain part of the session ID (e.g. “ethz.ch”) is used to compare with the user home domain FQDN
(cf. section 4.5.4.5.1.1) to check for roaming.
4.5.4.2.7 Time Synchronization
The AAAC clients are responsible to generate the session ID and the timestamps of the DIAMETER
messages (cf. section 4.5.4.5.2). Within one domain all AAAC clients and the AAAC server (home or
foreign) should use a synchronized clock. This synchronization is achieved by NTP. Each domain has an
NTP server and the AAA machines have NTP clients installed with synch with the server).
4.5.4.2.8 Counters
The accounting and charging component will rely on counters per session, i.e. absolute counters. Table 23
shows an example of an accounting DB, containing rows for one session (not all MySQL columns are
shown). In the example we made the assumption that DIAMETER “interim” messages are generated after
constant interval (3 minutes).
… EventTime SessionTime AccType BytesToUser …
… 2003-01-12 22:40:00 0 “start” 0 …
… 2003-01-12 22:43:00 180 “interim” 250 …
… 2003-01-12 22:46:00 360 “interim” 259 …
… 2003-01-12 22:48:00 480 “stop” 478 …
2 “1234” is a decimal value.
Table 23: The accounting DB: Use of counters in a session
D0103v1.doc 123 / 168