Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan Moby Dick Consolidated System Integration Plan

kt.agh.edu.pl
from kt.agh.edu.pl More from this publisher
27.03.2014 Views

D0103v1.doc Version 1 6.7.2003 5.2.5.4 Paging area update When a mobile terminal has entered a dormant mode, its interface’s activity might be reduced, but scanning of paging area advertisement information must be possible to be detected, indicating that the mobile terminal has entered a new paging area. When a new paging area identifier has been received, the respective paging area ID has to be notified to the PA by means of paging area update signalling (Dormant Registration, having the paging area update flag set). This signalling is to be done on IP level when no support from access technology’s link-layers can be expected and requires that the mobile terminal sends an IP paging area update message to the PA. This IP signalling is to be allowed to go through the respective AR without previous establishment of a SA. Alternatively, the paging area update can be sent through the current AR's paging attendant. In the latter case, the temporarily acquired CoA is to be sent with the update message to allow replies to be forwarded from the current AR to the mobile terminal. In both cases, the disadvantage of not taking support from access technologies into account is that the mobile terminal has to enable full IP functionality for paging related signalling while being dormant. This procedure can be improved when getting support from access technologies by means of detecting a mobile terminal’s movement on link-layer (management/control frame messaging) and generation of the IP paging area update control messages on ARs, which are to be sent to the respective PA. This avoids IP activity on a mobile terminal for paging area update signalling to the PA while being dormant. This kind of technology specific support is allowed by the concept but to be detailed in the future for appropriate access technologies. MN AR1 AR2 AAA PA HA 2 1 Paging area ID advertisements [RtAdv option or L2 beacon extension] No L2 interaction on acces link 3 1a 2 With L2 interaction on acces link 1b 3 L2 interaction with Paging attendant in ARs Figure 104 : Paging Area update signalling D0103v1.doc 160 / 168

D0103v1.doc Version 1 6.7.2003 No. Message Parameters Remarks 1 RtAdv or L2 beacon …, paging area ID Paging area info advertisement 2 Dormant Mode Request …, sequence #, paging area ID, Includes AH for PA reg. lifetime 3 Dormant Mode Reply …, status code, sequence #, lifetime authentication at ARs. Status code to be checked, paging key is the same. Not included unless requested. 1a L2 control msg. [technology specific] L2 interaction, AR generated IP Dormant Mode Request message (paging area update). 1b L2 control msg. [technology specific] Arrival of IP Dormant Mode Reply at AR triggers L2 interaction. Table 53: Messages for Paging Area Updates signalling 5.2.6 Charging 5.2.6.1 Signalling Flow Basically post-paid and prepaid business models are possible, however only the post-paid scenario will be implemented. Prepaid scenario will need further investigations. In the ongoing text we will therefore focus only on the post-paid scenario. 5.2.6.1.1 Post-paid Scenario In the post-paid scenario, the AAAC.h server stores the accounting data in the accounting database. This database in conjunction with the customer database will contain all necessary information needed to perform charging by applying tariffs. The detailed structure of the accounting database is described in section 4.5.4.4. Section 4.5.4.5 contains details about the charging database, section 0 contains details about the customer database and section 4.5.4.9 describes the data warehouse, i.e. the used accounting data. Cf. Figure 105 for a graphical representation of the signalling: Accounting data is added to the database after starting a session, during a session and after the session was closed (message 1). The charging component (CC) will periodically contact the accounting database and extract new records that have not been yet used for charge calculation purposes (messages 2, 3). For the post-paid scenario it is sufficient that the CC will contact the database only once a day, typically during a period of low accounting activities. The CC uses other database—the charging and customer database—to manage the charges. The tariff definitions will be stored either in CC itself, since they will not change during the Moby Dick trials. On the basis of the accounting data and the entries in the customer database, the appropriate tariff will be applied (messages 4 and 5). After the charge calculation is finished the result (i.e. the charge) is written back in the charging database (messages 6,7). The used rows from the accounting database for the current charge calculation, will be marked (messages 7) and then copied to another database (not drawn in the figure). D0103v1.doc 161 / 168

D0103v1.doc Version 1 6.7.2003<br />

No. Message Parameters Remarks<br />

1 RtAdv or L2 beacon …, paging area ID Paging area info<br />

advertisement<br />

2 Dormant Mode Request …, sequence #, paging area ID, Includes AH for PA<br />

reg. lifetime<br />

3 Dormant Mode Reply …, status code, sequence #,<br />

lifetime<br />

authentication at ARs.<br />

Status code to be checked,<br />

paging key is the same. Not<br />

included unless requested.<br />

1a L2 control msg. [technology specific] L2 interaction, AR generated<br />

IP Dormant Mode Request<br />

message (paging area update).<br />

1b L2 control msg. [technology specific] Arrival of IP Dormant Mode<br />

Reply at AR triggers L2<br />

interaction.<br />

Table 53: Messages for Paging Area Updates signalling<br />

5.2.6 Charging<br />

5.2.6.1 Signalling Flow<br />

Basically post-paid and prepaid business models are possible, however only the post-paid scenario will be<br />

implemented. Prepaid scenario will need further investigations. In the ongoing text we will therefore<br />

focus only on the post-paid scenario.<br />

5.2.6.1.1 Post-paid Scenario<br />

In the post-paid scenario, the AAAC.h server stores the accounting data in the accounting database. This<br />

database in conjunction with the customer database will contain all necessary information needed to<br />

perform charging by applying tariffs. The detailed structure of the accounting database is described in<br />

section 4.5.4.4. Section 4.5.4.5 contains details about the charging database, section 0 contains details<br />

about the customer database and section 4.5.4.9 describes the data warehouse, i.e. the used accounting<br />

data.<br />

Cf. Figure 105 for a graphical representation of the signalling: Accounting data is added to the database<br />

after starting a session, during a session and after the session was closed (message 1). The charging<br />

component (CC) will periodically contact the accounting database and extract new records that have not<br />

been yet used for charge calculation purposes (messages 2, 3). For the post-paid scenario it is sufficient<br />

that the CC will contact the database only once a day, typically during a period of low accounting<br />

activities. The CC uses other database—the charging and customer database—to manage the charges. The<br />

tariff definitions will be stored either in CC itself, since they will not change during the <strong>Moby</strong> <strong>Dick</strong> trials.<br />

On the basis of the accounting data and the entries in the customer database, the appropriate tariff will be<br />

applied (messages 4 and 5). After the charge calculation is finished the result (i.e. the charge) is written<br />

back in the charging database (messages 6,7). The used rows from the accounting database for the current<br />

charge calculation, will be marked (messages 7) and then copied to another database (not drawn in the<br />

figure).<br />

D0103v1.doc 161 / 168

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!