Content for  TS 23.251  Word version:  18.0.0

An example of an information flow for redirection in UTRAN is shown below. In this example an attach request from a non-supporting UE is directed to three different CN operators. The UE is not a subscriber of any of the sharing operators. The UE is not served by any shared SGSN nor by any shared MSC. The UE is furthermore not under operator coordination. The first rejects since it has no roaming agreement with the subscribers Home PLMN or rejects due to CS/PS coordination required. The second rejects because of a roaming restriction found in HLR. The third CN operator accepts and completes the attach request. The different "MSC/SGSNs" in the example below shall be seen as different CN operators. One specific CN operator may also have several pooled MSCs/SGSNs connected to the RNC if Iu-flex is used.

If the RNC finds no more MSC/SGSN to redirect to after receiving a Reroute Command message, e.g. step 5 or step 9, it compares the cause code with cause codes from other Reroute Command messages it has earlier received for this UE. A cause code ranking is done and the "softest" cause code is chosen and the corresponding saved NAS attach reject message is returned to the UE. Each CN node that receives an Initial UE, shall run its own authentication procedure. This may in some rare situations cause the UE to be authenticated more than once, however the trust-model used is that one CN operator shall not trust an authentication done by another CN operator. This will of course not be an optimal usage of radio resources, but given the rare occurrence of this, the increased signalling should not be of any significance. During the redirect procedure the RNC keeps a timer, which corresponds to the UE timer of releasing the RR connection (20 seconds). If the RNC when receiving a Reroute Command message finds that there is not sufficient time for another redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try).

An example of an information flow for redirection in GERAN is shown below. In this example an attach request from a non-supporting UE is directed to two different CN operators. The UE is not a subscriber of any of the sharing operators. The UE is not served by any shared SGSN nor by any shared MSC. The UE is furthermore not under operator coordination. The first CN operator rejects since it has no roaming agreement with the subscribers Home PLMN or rejects due to CS/PS coordination required. The second CN operator accepts and completes the attach request. The different "MSC/SGSNs" in the example below shall be seen as different CN operators. One specific CN operator may also have several pooled MSCs/SGSNs connected to the BSC if A/Gb-Flex is used. Separate call flows are shown for CS domain and for PS domain.

If the BSC finds no more MSC to redirect to after receiving a Reroute Command message, it compares the cause code with cause codes from other Reroute Command messages it has earlier received for this UE. A cause code ranking is done and the "softest" cause code is chosen and the corresponding saved attach reject message is returned to the UE. Each CN node that receives a Complete Layer 3 Information shall run its own authentication procedure. This may in some rare situations cause the UE to be authenticated more than once, however the trust-model used is that one CN operator shall not trust an authentication done by another CN operator. This will of course not be an optimal usage of radio resources, but given the rare occurrence of this, the increased signalling should not be of any significance. During the redirect procedure the BSC keeps a timer, which corresponds to the UE timer of releasing the RR connection (20 seconds). If the BSC when receiving a Reroute Command message finds that there is not sufficient time for another redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try).

If the BSC finds no more SGSN to redirect to after receiving a BSSGP DL-UNITDATA message with the redirection indication flag set, it compares the cause code with cause codes from other BSSGP DL-UNITDATA messages it has earlier received for this UE. A cause code ranking is done and the "softest" cause code is chosen and the corresponding saved attach reject message is returned to the UE. Each CN node that receives a BSSGP UL-UNITDATA, shall run its own authentication procedure. This may in some rare situations cause the UE to be authenticated more than once, however the trust-model used is that one CN operator shall not trust an authentication done by another CN operator. This will of course not be an optimal usage of radio resources, but given the rare occurrence of this, the increased signalling should not be of any significance. During the redirect procedure the BSC keeps a timer, which corresponds to the UE timer of releasing the RR connection (20 seconds). If the BSC when receiving a BSSGP DL-UNITDATA message with the redirection indication flag set finds that there is not sufficient time for another redirect, further redirect attempts are stopped (for this attach request message). The UE will repeat its attach request four times (each time waiting 15 seconds before it re-establishes the RR connection for another try).

An example of an information flow at registration in current domain when already registered in opposite domain is shown below. This example shows network selection for a non-supporting UE in a shared UTRAN network. The UE is not a subscriber of any of the sharing operators. The UE is not under operator coordination. Due to PS Handover the UE is registered in the PS domain of the shared UTRAN network when the registration attempt for the CS domain occurs.