<<

. 66
( 132 .)



>>


Mode Functions provided byte 1
D/C SEQ No.
Segmentation and reassembly byte 2
SEQ No. P HE
User data transfer E
LI
Discard of errored SDU




...
Concatenation
Acknowledged E
LI
Padding
Mode (AM)
Ciphering
Data
In sequence PDU delivery
Duplicate detection
byte n
PAD/STATUS
Error and flow control

Figure 6.48 RLC acknowledged mode PDU

mode and the format of the data PDU are shown in Figure 6.48. There are a number of
other PDU formats since this mode has control functions associated with it. Here, the
sequence number is 12 bits and is used for retransmission control as well as reassembly.
The D/C bit indicates whether this is a data (1) or control (0) PDU. The P bit indicates
polling and is used to request a status report (if 1) from the receiver. The HE is a 2-bit
¬eld which indicates what follows. Currently only two values are de¬ned to indicate data
(0) or a length ¬eld (1).
The data PDU may have a status PDU piggybacked to the end of the frame to report
the status between the two entities. Alternatively, a separate status PDU may be send.
The format of the status PDU is shown in Figure 6.49.
The PDU type ¬eld is 3 bits in length and indicates that this is either a status, reset or
reset acknowledge PDU. The other ¬ve values are currently reserved. The reset procedure
is used to reset the RLC peer entities. During this procedure the hyperframe numbers
(HFN) in UTRAN and the UE are synchronized. The status ¬eld (SUFI) contains status
information and is indicated with a PDU type of 000. There are currently eight different
types de¬ned. The format is a type“length“¬eld structure, where the length and ¬eld are
dependent on the type. The possible types are also listed in Figure 6.49. The windowing
is for ¬‚ow control. Perhaps the most common status is the acknowledgement, Figure 6.50,
which acknowledges receipt of all PDUs with sequence number less than last sequence
number (LSN).

PDU type value Description
0 No more data
PDU 1 Window size
byte 1
D/C SUFI1
type
2 Acknowledgement
byte 2
SUFI1 3 List
4 Bitmap
...




5 Relative list
6 More receiving window
SUFIk
7 More receiving window ack
byte n
PAD 8-15 Not currently used

Figure 6.49 RLC status PDU
316 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM


type = ACK

LSN


Figure 6.50 RLC acknowledgement


6.12.4 Media access control (MAC)
The MAC layer is responsible for mapping the logical user data and control channels
to the transport channels. It ensures that the transport format for a data source provides
for ef¬cient usage of the transport channels. This is particularly important for ˜bursty™
data ¬‚ows. The MAC can also prioritize data ¬‚ows on the common and shared transport
channels. When a mobile device is receiving on a common downlink channel or when it is
sending on the RACH it needs to be identi¬ed uniquely within the cell. This indenti¬cation
is also performed at the MAC layer. Multiplexing and demultiplexing of upper-layer
packets on both the common and dedicated channels is also performed at this layer. If a
higher data rate than is assigned on a common channel is required by the mobile device,
the MAC layer can switch over to a dedicated channel if requested to do so by the RRC.
The MAC layer functions can be summarized as follows:

• mapping between logical and transport channels;
• selecting the transport format for each channel;
• QoS provisioning and scheduling;
• UE identi¬cation on common transport channels;
• multiplexing/demultiplexing of PDUs from upper layers onto both common and dedi-
cated transport channels;
• encryption of RLC transparent mode data.

The architecture of the MAC layer is broken into three parts: the MAC-d, which handles
dedicated data channels, the MAC-c/sh, which handles the common control and shared
channels, and the MAC-b which deals with the broadcast channel. For each cell instance,
there will only be one MAC-b and one MAC-c/sh; however, there will be one MAC-d
for each user connection. The architecture is presented in Figure 6.51. The MAC-d to
MAC-c/sh interface will often be internal to the RNC, but may be connected across the
Iur interface when the SRNC of the user is not the CRNC of the common channel. This
is described later. Note on the diagram that in some instances, the BCCH information can
also be sent on the FACH.
As an example of data ¬‚ow through the MAC layer, consider a dedicated logical traf¬c
channel (DTCH), in the downlink direction. This channel is mapped at the MAC layer
onto the appropriate transport channel, as directed by the RRC protocol. This mapping
can be any one of the three options shown in Figure 6.52.
For a voice call, it makes sense to map this logical channel to a dedicated transport
channel, DCH, since the nature of the application will have little change over a relatively
long duration (of the order of minutes). However, many data applications, for example
6.12 RADIO INTERFACE PROTOCOL ARCHITECTURE 317


either internal
BCCH PCCH BCCH CCCH CTCH DCCH DTCH
or Iur interface




MAC-d




MAC-b MAC-c/sh




BCH PCH FACH RACH CPCH DSCH DCH DCH

Figure 6.51 MAC architecture


DTCH



MAC




FACH DSCH DCH


Figure 6.52 Logical to transport channel mapping

short emails or DNS queries, only send small amounts of information infrequently. There-
fore, these can be mapped into either the common forward access channel (FACH) or the
downlink shared channel (DSCH), where they share channel bandwidth with other users,
allowing for statistical multiplexing. The RNC will monitor the bandwidth requirements
and volume of data of the logical channel, and should it exceed some threshold, move
it to a dedicated transport channel. Conversely, should the rate fall below a threshold, it
can be moved from a dedicated to a common/shared channel.
The MAC layer adds a protocol overhead, and the type of overhead added depends on
the logical to transport channel mapping.
For a DTCH/DCCH that is mapped to a DCH, there are two possible situations. The
¬rst is where there is no multiplexing of channels on the MAC, i.e. only one logical
channel in the transport channel. Here there is no MAC header present (Figure 6.53(a)).
The second is where multiplexing is present, and in this case, the channel is identi¬ed
using a C/T ¬elds (Figure 6.53(b)).
318 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM



MAC SDU
a)




C/T MAC SDU
b)


Figure 6.53 MAC format for dedicated transport channels


The C/T ¬eld identi¬es the logical channel number (1“15) where there are multiple
logical channels in either the DCH, FACH or RACH. Channel multiplexing is used when
there are a number of radio bearers de¬ned to be carried on the same transport channel.
An example of this is a signalling connection which de¬nes a number of radio bearers,
using different RLC modes. Which one is being used is identi¬ed by the C/T ¬eld.
When data is on the FACH/RACH, or on the DSCH, the speci¬c UE needs to be
identi¬ed. A target channel type ¬eld (TCTF) ¬eld is included, to identify the channel
type, i.e. that this is a DTCH/DCCH. The UE ID type and UE ID ¬elds are in the
header, and optionally the C/T ¬eld, should multiplexing within a single UE be available
(Figure 6.54).

• UE ID type: indicates whether the following UE ID is a U-RNTI (32 bits) or a C-RNTI
(16 bits), both of which are explained in Section 6.16.2.
• UE ID: this will be either a U-RNTI or a C-RNTI as identi¬ed by UE ID type.

The various control channels, if transported on their own transport channel (e.g. PCCH
mapped to PCH) do not require any header. However, in the case of logical channels
mapped to the RACH/FACH, a TCTF header ¬eld is required, as shown in Figure 6.55.

• TCTF: this provides an identi¬cation of which logical channel type (e.g CCCH) is
carried in the payload. It is required on the FACH and RACH channels. Note that the
number of bits is dependent on the channel. The values currently designated are as
shown in Figure 6.56.


UE ID
TCTF UE ID C/T MAC SDU
type


Figure 6.54 MAC format for data on common/shared channels



TCTF MAC SDU


Figure 6.55 MAC format for control channels on FACH/RACH
6.12 RADIO INTERFACE PROTOCOL ARCHITECTURE 319



FACH RACH

TCTF Channel TCTF Channel
00 BCCH 00 CCCH

01000000 CCCH 01 DCCH/DTCH
10000000 CTCH
11 DCCH/DTCH

Figure 6.56 TCTF values for the FACH/RACH


User data



RLC Segmentation
User data Pad
User data
and padding

Seq Seq RLC header
User data User data
1 2 unack mode

MAC C/T Seq C/T Seq
User data User data MAC-d
1 1 1 2

UE UE C/T Seq UE UE C/T Seq
TCTF User data TCTF User data MAC-c/sh
type ID 1 1 type ID 1 2

FACH frame protocol


Figure 6.57 Data passing through RLC and MAC layer

<<

. 66
( 132 .)



>>