Conclusion: Handled by the drafting group on Registration.
S2-001462 from Ericsson: Triggering the CSCF Selection Function. Home Network Control case.
This contribution isolates the “S-CSCF selection trigger” from the “S-CSCF Selection Function” (S-C SF) and evaluate that, in term of flow exchanges, it’s preferable to have the triggering in the HSS than in the I-CSCF.
Discussion: A new entity, the S-CSCF Selection function, is abbreviated by “S-C SF”, which is confusing.
The “update location” is used to update the address of the S-CSCF in the “loc serv”, but Alcatel mentioned these flows are useless: it can be the S-C SF which directly update the S-CSCF address in the “Loc Serv”: it’s useless to go through the “?”.
AT&T appreciated the way of splitting the problem: first, identifying the involved functions as separate entities (figure 1), and then allocating these functions to existing entities (or bundling).
BT stressed that these flows are not very secure because the selected S-CSCF is never contacted, so it can be selected even if it’s out of order. A possible solution would be to have the “update location” messages sent after the S-CSCF has been reached.
Taking this into account, they stressed that it’s the same number of exchanges whether the “?” is in the I-CSCF or in the HSS.
If the selected S-CSCF crashes, the registration procedure has to be executed again in this proposal. But then it’s not clear how this re-registration procedure is triggered. Session timer is a possibility. The same problem also happens in GSM, where a HLR is not aware of an MSC crash.
These flows should be distinguished for the h- and v- S CSCF controlled cases.
The messages between the S CSCF and the S C SF are for further study and are not intended to be solved by this contribution.
Dostları ilə paylaş: | 
