Page 154 - From GMS to LTE

140 From GSM to LTE-Advanced Pro and 5G

to react to a Paging message;
●
to start a data session (Packet Data Protocol (PDP) context activation);
●
to access the network during an ongoing data session for which the physical air
●
interface connection was released by the network owing to long inactivity.
For all scenarios above, the mobile device needs to access the network to request a
connection over which further signaling messages can be exchanged. As can be seen in
Figure 3.14, the mobile device starts the initial network access procedure by sending
several preambles with a length of 4096 chips. The time required to transmit the 4096
chips is exactly 1 millisecond. If the mobile device receives no answer from the network,
it increases the transmission power and repeats the request. The mobile device keeps
increasing the transmission power for the preambles until a response is received or the
maximum transmission power and number of retries have been reached without a
response. This is necessary as the mobile device does not know which transmission
power level is sufficient to access the network. Thus the power level is very low at the
beginning, which on the one hand creates only low interference for other subscribers in
the cell but on the other hand does not guarantee success. To allow the network to
answer, the preambles are spaced three slots apart. Once the preamble is received cor-
rectly, the network then answers on the AICH. If the mobile device receives the message
correctly, it is then aware of the transmission power to use and proceeds by sending a
10‐ or 20‐millisecond frame on the PRACH, which contains an RRC Connection
Request message. As the spreading factor of the PRACHs is variable, the message can
contain between 9 and 75 bytes of information.
To avoid collisions between different mobile devices, the PRACH is divided into 15
slots. Furthermore, there are 16 different codes for the preamble. Thus, it is very unlikely
that two mobile devices use the same slot with the same code at the same time.
Nevertheless, if this happens, the connection request will fail and has to be repeated by
the mobile devices as their requests cancel out each other. Once the RNC has received
the RRC Connection Request message as shown in Figure 3.14, it will allocate the
required channels in the radio network and on the air interface. There are two possibilities
the RNC can choose from:

The RNC can use a DCH for the connection as shown in Figure 3.14. Thus, the mobile
●
device changes into the Cell‐DCH RRC state (see also Section 3.5.4). Using a DCH is
a good choice for the network in case the Connection Request message indicates
that the mobile device wishes to establish a user data connection (voice or packet‐
switched data).
The RNC can also decide to continue to use the RACH and FACH for the subsequent
●
exchange of messages. The mobile device will thus change into the Cell‐FACH state.
The decision to use a shared channel instead of a DCH can be made, for example, if
the Connection Request message indicates to the network that the channel is only
required for signaling purposes, such as for performing a location update procedure.

After choosing a suitable channel and reserving the necessary resources, the RNC
replies with an RRC Connection Setup message to the mobile device via the FACH. If a
DCH was established for the connection, the mobile device will switch to the new chan-
nel and return an RRC Connection Setup Complete message. This message confirms
the correct establishment of the connection, and is also used by the mobile device to