12.12.2012 Views

UMTS Networks : Architecture, Mobility and Services

UMTS Networks : Architecture, Mobility and Services

UMTS Networks : Architecture, Mobility and Services

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

368 <strong>UMTS</strong> <strong>Networks</strong><br />

Figure 11.16 CS SRNS relocation—UE not involved<br />

If the target RNC is able to provide resources to h<strong>and</strong>le incoming SRNC functionality<br />

it send an acknowledgement back to the CN, which relays this acknowledgement<br />

to the source RNS. From the RNC 1 point of view, this acknowledgement is a<br />

comm<strong>and</strong> to start relocation, since everything should now be ready in the target<br />

RNC. Upon receiving the ranap relocation comm<strong>and</strong>, the original SRNC (RNC 1)<br />

starts to forward data to the target SRNC (RNC 2). The expected SRNC (RNC 2)<br />

realises there are incoming data <strong>and</strong> lets the CN domain know that SRNS relocation<br />

has been detected with the message ranap relocation detect. Optionally, the source<br />

SRNC (RNC 1) may send a rnsap srnc relocation commit message to the target<br />

SRNC (RNC 2) over the Iur interface. In the case of SRNC relocation in which the UE<br />

is not involved, the UE is unaware of the message flow described above. If there is a<br />

need to carry out any RRC procedures, they are performed after the RANAP Relocation<br />

Detect message. The UTRAN may, for instance, send an rrc utran mobility<br />

information message to the UE. It is by means of this message that the UTRAN

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

Saved successfully!

Ooh no, something went wrong!