UMTS Packet Data Sessions

From a network perspective, packet data services in the 3GPP Release 1999
architecture use largely the same mechanisms as used for GPRS data, the
big difference being the user data rates that can be supported. One notable
difference is that the Gb interface of GPRS (between the SGSN and BSC)
is replaced by the Iu-PS interface, which uses RANAP as the application
protocol. This change includes the fact that IP over ATM is used between
the SGSN and RNC. Thus, an IP network is set up from GGSN to SGSN to
RNC. Consequently, the GTP-U tunnel can be relayed from the GGSN
through the SGSN to the RNC, rather than terminating at the SGSN. The
GTP-C tunnel, however, terminates at the SGSN, because the application
protocol between RNC and SGSN is RANAP, rather than GTP. The establishment
of the tunnel is still under the control of the SGSN. Figure 6-24
shows the Control Plane for packet data services in UMTS and Figure 6-25
shows the User Plane.

Packet data services are established in UMTS in largely the same manner
as in GPRS—through the activation of a PDP context with an Access
Point Name (APN), QoS criteria, and so on. One significant difference between UMTS and standard GPRS, however, involves SRNS relocation.
Because of the fact that the GTP-U tunnel terminates at the RNC rather
than the SGSN, relocation of the UE to another RNC may require the
buffering of packets at the first RNC and a subsequent relay of those packets
to the second RNC once relocation has taken place. That relay occurs via
the SGSN. In case the two RNCs are connected to two different SGSNs,
then the path for buffered packets is from RNC1 to SGSN1 to SGSN2 to
RNC2.

From an air interface perspective, UMTS provides greater flexibility
than GPRS in terms of how resources are allocated for packet data traffic.
Not only does UMTS offer a greater range of speeds, but the WCDMA air interface has a selection of different channel types that can be used for
packet data. In the uplink, the RACH, CPCH, and DCH are available. In
the downlink, the DCH, FACH and DSCH are available. The choice of channel
to be used is under the control of the RNC and is chosen depending on
the characteristics of the session required by the user—e.g. high-volume
streaming versus low-volume bursty traffic.

For a non-bursty service such as video streaming or for large file transfers,
the DCH might be the best option as it has the greatest throughput
capability. It has the disadvantage, however, of taking time to establish. For
small amounts of bursty traffic, the RACH or CPCH in the uplink is likely
to be more suitable. These are faster to establish, but cannot support rates
as high as the DCH. In the case of the RACH, there is likely to be only one
per cell (certainly no more than a few), whereas there can be many CPCH
channels. Moreover, the CPCH can carry more data than the RACH.
In the downlink, the FACH is useful for small amounts of bursty user
data. Like the RACH, however, the number of FACH channels is very limited.
Another option in the downlink is the DSCH, which is a channel that
is time-multiplexed among several users. It can support higher throughput
than the FACH, through not as high as the DCH. It is, however, much more
suited to bursty traffic than the DCH.